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SECTION  1 


INTRODUCTION 


This  project  began  in  1979  in  response  to  a  perceived  need  for 
a  method  of  producing  more  reliable  software  cost  and  schedule 
estimates  for  embedded  software,  and  an  idea  that  better  estimates 
could  be  derived  from  the  developmental  process  rather  than  mainly 
on  the  characteristics  of  the  software  product  being  developed.  In 
this  approach,  the  scope  of  the  process  was  taken  to  include  both 
the  software  development  (usually  by  a  contractor)  and  the 
acquisition  procedures  normally  followed  by  the  Government.  These 
two  distinct  activities  were  joined  together  because  of  their 
intimate  interaction,  particularly  when  the  software  procured  is 
embedded  in  a  military  system. 

To  limit  the  scope  of  the  initial  implementation,  the 
acquisition  process  was  modeled  to  conform  to  the  AFR  800-series 
regulations,  and  to  only  include  the  Full  Scale  Development  Phase  of 
the  process.  The  modeling  approach  and  associated  simulator, 
however,  are  not  inherently  subject  to  these  limitations,  and  the 
possibility  of  wider  application  is  contemplated. 

The  development  of  the  Software  Acquisition  Process  (SWAP) 

Model  has  proceeded  continuously  for  several  years  under  different 
sponsors,  names  and  project  numbers.  This  report  documents  the 
results  achieved  during  FY81  on  Project  6820,  under  the  sponsorship 
of  ESD/ACCE.  In  order  to  obtain  independent  readability  in  this 
year's  end  report,  a  "background"  section  is  included.  This 
provides  descriptions  of  the  concepts  employed  by  the  Model,  as 
necessary  to  understand  the  work  accomplished  during  FY81. 


1.1  POTENTIAL  USES 

A  number  of  advantageous  uses  are  seen  for  the  Simulation 
Model.  These  include: 


a.  Improved  accuracy .  This  should  result,  in  part,  from  the 
explicit  contractual  situation. on  which  the  Model  bases  its 
estimates. 

b.  Measures  of  uncertainty.  The  Simulation  Model  will  produce 
measures  of  an  estimate  diaper*- '  a,  and  corresponding  estimate 
ranges .  as  well  as  point  . «  lea 
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c.  More  flexibility.  The  Model's  process  can  include  the 
effects  of  changes  in  development  technique  which  will  occur  as  the 
practice  of  software  engineering  matures. 

d.  More  versatility.  The  Simulation  Model  can  support  many 
uses  in  addition  to  the  generation  of  cost  and  time  estimates.  In 
concept,  the  simulation  program  (i.e.,  the  Simulator)  can  be  applied 
to  equipment  procurement,  total  system  acquisition,  acquisitions 
conducted  per  different  regulations,  and  many  other  processes. 

While  the  main  driving  force  behind  the  Simulation  Model  is  the 
need  for  better  software -related  cost  and  schedule  estimates,  the 
Model  could  be  effectively  employed  for  other  purposes,  such  as  the 
following: 

a.  The  diagrams  of  the  acquisition  process  can  be  useful  for 
training  military  and  support  personnel  for  work  on  software 
acquisitions.  The  simulation  program  (i.e.,  the  Simulator)  can  help 
the  training  by  presenting  a  dynamic  picture  that  illustrates  the 
effects  and  consequences  of  alternative  actions  and  decisions. 

b.  The  diagrams  should  be  helpful  in  project  planning.  They 
c  provide  a  checklist  that  insures  that  important  activities  and 
products  are  not  overlooked,  and  that  contractual  events  and 
products  are  scheduled  realistically.  Past  experience  on  many 
projects  indicates  that  this  need  has  often  been  overlooked,  with 
negative  consequences.  The  Simulator  can  also  improve  system 
planning  trade-off  analyses  that  are  performed  to  establish  the 
capability  and  capacity  mix  for  a  particular  procurement. 

c.  The  Simulator  will  be  useful  for  evaluating  contractor 
proposals  by  helping  to  determine  the  extent  to  which  the  proposed 
schedule,  allocated  costs,  development  plans,  etc.  are  consistent 
with  Simulator  forecasts  and  previous  ESD  experience. 

d.  During  contract  monitoring,  the  Simulator  can  help  evaluate 
the  consequences  of  milestone  slippage,  delays  induced  by 
Engineering  Change  Propsals  (ECPs),  ongoing  costs  vs.  developmental 
progress,  etc. 

After  the  Model  is  put  into  routine  use  and  data  associated 
with  contracts  is  accumulated,  the  Model  accuracy  will  improve.  Its 
processes  and  parameter  values  will  more  closely  reflect  those  found 
on  ESD  projects.  As  this  happens,  the  Model  will  evolve  in  concert 
with  improvements  in  the  software  development  art.  The  resultant 


parameter  changes  will  provide  an  objective  measure  of  a  "trend 
line"  and  enable  more  accurate  future  forecasts.  At  the  same  time, 
the  data  obtained  on  ongoing  projects  will  enable  performance  on 
different  contracts  to  be  objectively  and  numerically  compared. 

The  graphic  description  of  the  acquisition  process  provided  by 
the  Model  presents  a  compact  view  of  how  the  Air  Force  obtains 
embedded  software.  This  view  will  improve  understanding  of  the 
process  and  help  to  determine  ways  by  which  it  can  be  improved.  The 
objectives  sought,  for  example,  may  be  ways  to  reduce  the  overall 
time  or  costs,  to  obtain  a  more  reliable  product,  or  to  establish 
the  cumulative  impact  of  various  system  constituents  (including 
operating  functions,  support  functions,  and  data  items)  for  use  in 
tradeoff  studies  that  consider  each  constituent's  utility  value. 

Use  of  the  Simulator  allows  the  dynamics  of  the  process  to  be 
assessed  and  makes  it  practical  to  obtain  quantitative  answers  to 
complex  questions  for  both  general  acquisition  policy  and  specific 
procurements . 

Finally,  the  Model  can  also  be  used  as  a  research  tool  for 
investigating  development  alternatives  and  managerial  strategies. 

It  can  forecast,  for  example,  the  impact  of  different  manning 
assignments,  more  or  fewer  development  support  facilities,  longer  or 
shorter  schedules,  etc. 


1.2  ORGANIZATION  OF  THIS  REPORT 

This  report  has  been  organized  into  a  report  body  that  is 
supported  by  a  number  of  appendices.  The  appendices  generally  serve 
to  retain  the  documentation  developed  during  the  ongoing  definition 
and  design  activities,  as  well  as  detailed  information  that  would  be 
of  interest  to  a  small  subset  of  users.  While  these  appendices  are 
too  detailed  for  inclusion  in  the  report  body,  they  do  provide 
important  reference  and  backup  materials.  For  example,  Appendix  A, 
Process  Flow  Diagrams  and  Amplification  Notes,  expecially  Figure 
A-2,  Software  Acquisition  Process  Flow  Diagram  -  LoSim  Level, 
depicts  the  entire  FSD  Process,  at  the  level  planned  for  initial 
simulation.  This  figure,  which  was  revised  during  FY81,  may  be 
inspected  to  obtain  considerable  insight  into  this  acquisition  life 
cycle  phase.  While  many  readers  are  probably  familiar  with  (or  have 
participated  in)  the  FSD  process,  the  overall  complexity  and  degree 
of  interaction  of  the  process  are  not  so  apparent  when  experienced 
during  the  two  or  three  years  during  which  the  process  unfolds.  The 
diagram  can  impart  ar.  integrated  view  of  the  whole  procedure. 
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Similarly,  Appendix  B,  Model  Definition  Data,  contains 
estimates  of  the  manpower  and  elapsed  times  necessary  to  complete 
each  of  the  activities  depicted  in  Figure  A-2,  and  the  probabilities 
of  the  decisions  shown  there.  Appendix  B,  which  was  thoroughly 
revised  during  FY81,  may  also  be  of  interest  because  it  represents 
the  Figure  A-2  flow  diagram  network  in  tabular  form  for  use  by  the 
Simulator . 

Appendix  I  provides  design  documentation  for  the  four  computer 
programs  that  implement  the  Simulator,  and  Appendix  J  provides 
example  copies  of  output  reports  produced  by  the  Simulator.  Note 
that  the  appendix  designators  are  not  in  consecutive  order.  The 
appendix  designators  were  initially  established  in  the  FY79  Final 
Report  and  have  been  retained  for  consistency.  Those  appendices 
that  are  not  applicable  to  the  FY81  work  have  been  omitted. 

Finally,  Appendix  K  was  added  to  this  year's  report  to  preserve  the 
functional  analysis  by  which  the  Generic  Adaptation  Process  (GAP) 
was  formulated. 

The  body  of  this  report  is  organized  into  6  sections.  Section 
2  provides  background  information  that  "sets  the  stage"  for  this 
year's  work.  Section  3  describes  this  year's  accomplishments  and 
achieved  status.  Section  4  covers  program  operation  and  a  planned 
demonstration  that  was  deferred  to  early  FY82.  Section  5  develops  a 
plan  for  further  growth  of  the  Model,  and  Section  6  provides 
recommendations  based  on  the  year's  results. 
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SECTION  2 


BACKGROUND 


This  section  is  intended  to  provide  information  about  this 
project  to  persons  who  have  not  been  following  its  progress  and  have 
not  read  prior  years '  reports .  It  presents  the  ideas  and  concepts 
underlying  the  development  and  indicates  the  status  of  the  project 
at  the  end  of  FY81. 


2.1  BASIC  PREMISES 

During  preparation  of  the  Software  Acquisition  Process  Model, 
it  was  found  necessary  to  delineate  the  Model  and  to  limit  the  scope 
of  the  effort  to  fit  within  a  limited  budget  and  schedule.  The  set 
of  basic  premises  discussed  below  was  established,  therefore,  as 
guidance  for  the  initial  phases  of  this  work.  Some  of  these  apply 
to  the  acquisition  process  itself,  others  to  simplifications 
introduced  for  application  to  early  versions  of  the  Simulator. 

These  premises,  whenever  applicable,  are  referenced  by  Table  A-2, 
Process  Flow  Diagram  Amplification  Notes,  which  supports  the  Process 
Flow  Diagrams. 


2.1.1  Conformance  to  Military  Standards 

The  acquisition  process  modeled  is  intended  to  conform  to  all 
military  standards  and  regulations  that  are  normally  applied  to 
software  acquired  during  Electronic  System  procurements.  These 
include  MIL-STD-483,  Configuration  Management  Practices  for 
Equipment,  Munitions,  and  Computer  Programs*;  MIL-STD-1521A, 
Technical  Reviews  and  Audits  for  Systems,  Equipment,  and  Computer 
Programs^ ;  AFR  800-2,  Acquisition  Program  Management*;  and  AFR 
800-14,  Vol.  II,  Acquisition  and  Support  Procedures  for  Computer 
Resources  in  Systems^ .  If  deviation  from  these  practices  is  found  to 
be  necessary,  it  will  be  explicitly  described  (and  explained)  at 
each  point  in  the  process  where  it  occurs;  a  summary  list  of  all 
such  deviations,  if  any,  will  be  provided. 

2.1.2  System.  Segment ,  and  CPCI  Relationships 

The  relationships  among  activities  associated  principally  with 
a  system,  its  segments,  and  its  Computer  Program  Configuration  Items 
(CPCIs)  will  be  considerably  simplified  in  the  early 
implementations.  In  particular,  system  segments  can  be  used  in 


different  ways  on  different  contracts  and  are  therefore  not  fully 
amenable  to  generic  implementation.  For  this  reason,  the  Model 
addresses  the  CPCI  (level  3)  and  one  level  higher.  While  this 
higher  level  is  referred  to  as  "system"  (level  1)  it  could  as 
readily  represent  "system  segment"  (level  2).  The  choice  is 
dependent  on  the  nature  of  the  system  and  the  specific  contract (s) 
being  simulated. 

In  addition,  while  the  Model  is  designed  to  accommodate  a 
number  of  CPCIs,  it  will  treat  these  initially  in  a  somewhat 
simplified  manner.  As  thus  modeled,  all  CPCIs  will  initiate  and 
terminate  together  (e.g.,  in  the  System  Test),  and  proceed 
independently  in  between.  In  actual  practice,  the  various  CPCIs 
often  have  dependency  relationships  which  can  be  of  critical 
importance  to  the  success  of  a  project.  Later  versions  of  the  Model 
will  be  designed  to  accommodate  these  relationships. 

2.1.3  Validation  Phase  Activities 

The  Process  Model  of  the  Full-Scale  Development  Phase  presumes 
that  a  full  Validation  Phase  has  already  been  completed.  However, 
since  many  projects  omit  this  phase  but  incorporate  some  of  its 
activities  in  the  Full-Scale  Development  Phase,  provision  should  be 
made  for  such  activities'  incorporation  (e.g.,  the  preparation  of 
development  specifications)  in  the  FSD  Phase  Model.  Extension  of 
the  Model  to  the  Validation  Phase  is  planned  for  later 
implementation.  The  process  flow  developed  for  that  phase  will  be 
designed  so  that  selected  activities  can  be  readily  moved  into  the 
Full-Scale  Development  Phase. 

2.1.4  Support  Facilities 

The  Model  presumes  that  the  Test  and  Programming  Support 
functions  are  each  provided  by  separate  facilities.  On  some 
projects,  such  facilities  may  be  shared  (in  whole  or  in  part)  to 
support  both  functions.  The  Model  can  reflect  any  combined  use  of 
these  facilities. 

While  the  current  Model  provides  for  accumulating  the  costs  of 
operating  and  maintaining  support  facilities  and  for  the  impact 
resulting  from  their  late  availability,  it  does  not  include  the 
effect  of  contention  between  facility  users  or  the  results  of 
unscheduled  down  time.  These  latter  capabilities  will  be  added  in 
later  versions. 


2.1.5  Staged  Imp 1 ementat ion  Provls ions 

Procurement  regulations  allow  design  reviews  to  be  conducted  on 
a  single  or  on  an  incremental  basis.  The  Model  is  being  designed  to 
represent  the  incremental  approach.  While  this  decision  adds  to  the 
complexity  of  the  Model,  it  was  taken  because  the  single  design 
review  approach  would  not  support  the  trend  toward  staged 
development,  particularly  for  larger  systems.  The  Model  will  also 
accommodate  the  single  design  review  approach,  simply  by  setting  the 
number  of  design  increments  to  one. 

The  initial  Model  is  being  designed  to  accommodate  the 
following  incremental  or  staged  approach: 

a.  Each  CPCI  is  defined  by  a  specification  which  states  the 
functional  requirements  to  be  met  at  the  completion  of  the  current 
procurement  contract.  While  certain  follow-on  requirements  may  also 
be  explicitly  or  implicitly  defined,  these  are  treated  as  beyond  the 
scope  of  that  contract. 

b.  The  contractor  would  divide  the  total  contractual 
requirements  into  several  developmental  stages  (hereafter  called 
Developmental  Integration  Groups  (DIGs)).  This  division  would  be 
defined  in  a  phased  implementation  plan  that  is  included  within  the 
Computer  Program  Development  Plan  (CPDP) . 

c.  As  shown  in  Figure  1,  Staged  Group  Development  Example,  the 
contractor  would  then  proceed  with  the  design  of  the  first  DIG 
(DIG-I).  The  work  on  this  DIG  would  then  pass  successively  through 
the  various  phases  of  the  design  process  (including  Preliminary 
Design  Review  (PDR)  and  Critical  Design  Review  (CDR)),  and  through 
coding,  debugging,  integration,  and  contractor  internal  testing. 

The  work  might  also  be  subject  to  Preliminary  Qualification  Testing 
(PQT) ,  but  not  to  Formal  Qualification  Testing  (FQT). 

d.  The  design  and  implementation  of  the  other  DIGs  would 
proceed  in  order  behind  DIG-I.  Work  on  the  second  DIG  (DIG-II) 
would  begin  after  completion  of  high  level  design  on  DIG-I;  DIG-III 
would  similarly  start  after  DIG-II,  etc.  The  CDRs  and  other 
development  activities  for  each  DIG  would  proceed  in  the  same  order. 


e.  During  each  stage  of  development,  each  successive  DIG  would 
add  to  and  build  onto  the  aggregated  preceding  DIGs.  In  other 
words,  a  single  CPCI  would  be  built  in  successive  stages;  it  would 
not  be  built  as  separate  DIGs  to  be  joined  together  at  the  end. 


Development  Example 


f.  When  the  last  DIG  passed  through  each  development  stage, 
the  total  implementation  to  that  stage  would  be  complete. 

Therefore,  each  last  DIG  design  review  would  be  extended  to  survey 
the  totality  of  the  design,  in  addition  to  that  of  the  last 
functional  increment. 

g.  The  Model  documentation  includes  notation  to  accommodate 
the  incremental  development  concept.  The  notation  will  indicate 
(with  a  "D";  see  Figure  A-l)  those  processes  which  are  presumed 
developed  in  this  phased  manner.  In  addition,  when  a  development 
phase  is  complete  for  one  DIG,  the  process  must  return  to  that  phase 
to  begin  work  on  the  next  DIG.  This  type  of  return  is  shown  as  type 
"D"  on  the  Process  Flow  Diagram  (Figure  A-2)  and  in  the  Network 
Definition  Table  (Table  B-l)  (in  its  General  Data  Grp  column). 

h.  The  formal  test  activities  may  also  be  conducted  on  a 
similarly  staged  basis.  The  Model  supports  this  approach  by 
allowing  Test  Integration  Groups  (TIGs)  to  be  sequentially  processed 
in  a  manner  analogous  to  the  handling  of  DIGs.  Note  that  the  TIG 
division  involves  the  test  related  activities  and  applies  to  a 
totally  implemented  CPCI;  therefore,  TIGs  are  not  related  to  DIGs  in 
terms  of  usage  or  quantities. 

2.1.6  Incidental  Activities 

While  the  Model  is  planned  to  include  all  significant 
mainstream  acquisition  activities,  it  will  not  include  a  number  of 
incidental  tasks  that  are  essential  to  a  project  but  that  would  add 
needless  complexity  to  the  Model.  Instead,  the  cost  and  loading 
impact  of  such  activities  are  aggregated  into  larger  mainstream 
activities.  Similarly,  certain  events  and  activities  judged  too 
infrequent  or  too  inconsequential  to  the  Model  (though  not  to  the 
acquisition  process)  will  not  be  included.  Should  experience  or 
collected  data  indicate  that  some  of  these  incidental  activities  be 
added  to  the  Model,  this  can  be  done  in  a  later  version. 


2.1.7  Resource  Utilization 


c.  development  support  facilities; 

d.  test  support  fsciliti.es; 

e.  miscellaneous  other  resources. 


In  the  current  implementation,  only  manpower  resources  are 
being  assigned  to  specific  process  activities. 

2.1.8  Manpower  Categorization 

The  manpower  categories  listed  below  were  selected  for 
implementation  based  on  our  acquisition  program  experience.  In 
addition,  the  manpower  accounting  techniques  and  the  effects  of 
resource  limitation  are  described  below. 

a.  Contractor  Personnel.  Five  job  categories  were  selected 
for  individual  assignment  to  each  activity: 

(1)  systems  engineer  or  analyst; 

(2)  designer; 

(3)  programmer; 

(4)  test  engineer; 

(5)  support  (e.g.,  equipment  operator,  librarian, 
technical  writer). 

A  sixth  category,  management,  was  not  included  because  the  need 
to  subdivide  a  manager's  time  among  many  ongoing  tasks  made  its 
estimation  impracticable.  Aside  from  the  difficulty  in  estimation, 
results  would  be  inaccurate  because  management  styles  differ  widely 
and  would  generally  be  unknown.  Instead,  management  is  treated  as  a 
continuous  activity  with  a  utilization  profile  that  conforms  to  the 
estimated  (or  given)  needs  for  the  project  being  modeled. 

b.  Government  Personnel.  Three  job  classifications  were 
selected  for  personnel  assignment  to  specific  activities;  these 
reflect  the  three  principal  commands  involved  in  system  acquisition: 
The  Developing  Command  (e.g.,  Electronic  Systems  Division  (ESD)), 
the  Using  Command  (e.g..  Tactical  Air  Command  (TAC)),  and  the 
Supporting  Command  (e.g.,  Air  Force  Logistics  Command  (AFLC)). 
Further  specification  of  assignments  (e.g.,  to  Engineering,  Test, 
Configuration  Management ,  etc.)  can  be  provided  later,  if  needed. 
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c.  Initial  Implementation  Technique.  Because  personnel 
categories  are  likely  to  differ  for  different  contractors  and 
projects,  the  design  permits  any  number  of  categories  to  be 
selected. 

d.  Resource  Limitations.  The  rate  of  progress  on  any  project 
can  be  strongly  influenced  by  the  quantity  and  quality  of  the 
available  resources.  When  the  demand  for  a  resource  exceeds  its 
supply,  the  process  will  slow  accordingly.  This  process  behavior, 
while  inherently  simple,  requires  that  different  management 
strategies  be  devised  to  resolve  automatically  the  problem  of 
allocating  scarce  resources  among  competing  activities.  The  Model  0 
Simulator  did  not  reflect  the  effects  of  resource  limitation.  Model 
1  does  include  resource  limitation,  but  with  an  elemental  management 
strategy,  as  described  in  paragraph  3.3.1. 


2.2  DESIGN  APPROACH 

The  overall  developmental  effort  on  the  project  is  channeled 
into  three  principal  areas.  These  work  areas,  which  are  briefly 
introduced  below,  are  detailed  in  Paragraphs  2.2.1  through  2.2.3 
respectively. 

a.  Process  Definition.  This  work  involves  the  creation  of 
Process  Flow  Diagrams  and  Explanatory  Notes  which  represent  the 
process  whereby  computer  software  is  acquired  by  ESD  under  the  AFR 
800-series  regulations.  In  particular,  the  project  is  focused  on 
software  that  is  embedded  within  a  large  command,  control,  and 
communications  system  (see  DoDD  5000.29,  Management  of  Computer 
Resources  in  Major  Defense  Systems )5 .  For  maximum  realism  these 
Process  Flow  Diagrams  represent  both  sequential  and  concurrent 
activities.  Otherwise,  to  facilitate  communication,  they  resemble 
conventional  Von  Neumann  flowcharts. 

b.  Process  Quantification.  This  work  involves  establishing 
parameters  which  describe  each  element  within  the  Model,  and 
obtaining  appropriate  values  for  these  parameters. 

c.  Process  Simulation.  This  task  requires  that  the  Model  be 
mechanized  so  that  it  can  be  used  to  carry  on  synthetically  the 
processes  defined,  using  the  assigned  parameters.  It  can  thereby 
forecast  and  report  the  statistical  consequences  in  terms  of 
probable  schedule  and  cost  distributions.  A  discrete  event 
simulation  program  (i.e.,  the  Simulator)  is  the  mechanism  of  choice. 
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2.2.1  Process  Model  Definition 


Process  Flow  Diagrams  have  been  used  as  the  principal  swans  for 
describing  the  process  of  acquiring  embedded  software.  They  were 
developed  at  several  levels  of  detail,  as  follows: 

a.  a  global  view  of  the  whole  process; 

b.  a  high  simulation  level  (HiSim); 

c.  a  low  simulatirn  level  (LoSim) ;  and 

d.  expanded  views  of  LoSim  boxes  to  show  more  elemental 
relationships  as  needed. 

During  FY81,  work  on  these  diagrams  has  been  confined  to  the 
LoSim  level;  only  these  in  their  revised  form  are  contained  in 
Appendix  A. 

The  conventions  followed  by  these  Process  Flow  Diagrams  are 
described  in  Appendix  A,  Figure  A-l,  Flow  Diagram  Notation. 

Briefly,  they  define  three  types  of  basic  elements:  (1)  function 
boxes;  (2)  auxiliary  elements  (e.g.,  connectors);  and  (3)  lines  of 
flow.  These  conventions  should  be  understood  before  the  Process 
Flow  Diagrams  are  reviewed. 

The  LoSim  Process  Flow  Diagram  (Figure  A-2)  uses  approximately 
two  hundred  boxes  on  eleven  pages  to  represent  the  overall  process. 
The  function  represented  by  each  box  is  described  in  abbreviated 
English,  but  box  size  limitations  make  it  desirable  to  code  some  of 
the  information  via  box  shapes  as  well  as  in  special  fields.  The 
key  to  connector  and  box  number  locations  in  Table  A-l  will  aid  in 
following  the  flow  and  in  finding  boxes  referenced  in  the  tables  of 
Appendix  B.  This  diagram  was  prepared  during  FY79,  and  revised 
during  FYBO  and  FY81. 

The  main  flow  of  the  process  is  represented  using  three 
principal  box  types.  The  purpose  of  each  type  is  briefly  described 
below: 


a.  The  Activity  Box,  rectangular  in  shape,  represents  all 
developmental  activities  that  use  manpower  and  occupy  time. 

b.  Hie  Decision  Box,  diaaxmd  shaped,  is  used  to  represent  all 
decision  points  in  the  process.  Each  of  these  show  two  alternative 
exits  ("yes’'  or  "no")  that  the  process  can  take  as  a  result  of  a 
probability  function. 


c.  The  Personnel  Box,  small  and  pointed,  is  used  to  establish 
and  adjust  the  personnel  level  assigned  to  the  project.  This  box 
controls  the  size  of  the  pool  of  personnel  (by  type)  from  which  each 
activity  box  will  draw  its  manpower  when  it  is  activated. 

Each  box  contains  symbolic  fields  to  indicate  who  is  the  doer 
(i.e.,  the  contractor,  government,  or  both),  the  level  of  the 
activity  (e.g.,  system,  CPCI,  CPC,  etc.),  and  whether  the  activity 
is  multistaged  (see  2.1.5).  These  are  fully  described  in  Table  A-l. 

The  direction  of  flow  from  box  to  box  is  indicated  by  arrows 
while  the  logic  of  the  flow  is  indicated  by  letters  associated  with 
the  flow  lines.  These  indicate  AND/OR  relationships,  iterative  or 
forward  progression,  and  conditions  for  advancing  to  the  next 
developmental  stage.  These  also  are  defined  in  Table  A-l. 

2.2.2  Process  Quant iflcation 

The  Process  Flow  Diagrams  discussed  in  Paragraph  2.2.1  describe 
the  sequences  of  activities  and  decisions  involved  in  the 
acquisition  (including  development)  of  embedded  software.  Since; 
this  description  is  qualitative,  it  can  yield  no  quantitative 
predictive  output.  In  this  section,  means  are  described  for  adding 
quantity  and  probability  to  the  Process  Model. 

During  FY80,  a  set  of  quantitative  descriptors  and  appropriate 
values  for  each  box  were  established  for  a  "typical"  acquisition 
program.  This  year  the  data  for  a  typical  project,  now  referred  to 
as  the  "base  project",  was  used  to  create  a  pattern  for  resource 
utilization  that  can  be  scaled  to  obtain  appropriate  values  for  any 
given  (target)  project.  This  technique,  which  is  termed  the 
"Generic  Adaptation  Process"  (GAP),  is  defined  in  Appendix  K  and  is 
briefly  described  in  Paragraph  3. 3. I.e. 

The  base  project  parameters  and  the  values  assigned  to  each  box 
are  defined  and  given  in  Appendix  B.  The  values  shown  are  those  in 
effect  at  the  end  of  FY81.  The  main  parameters  are  briefly 
described  below. 

a.  The  Activity  Box  is  given  a  duration  (in  days)  and  a 
manning  level  for  each  of  five  personnel  types.  Manning  levels  may 
be  specified  in  fractions  (i.e.,  to  the  nearest  tenth  of  a  man)  to 
allow  for  personnel  time  sharing.  The  data  also  includes  scaling 
factors  to  be  applied  for  up  to  three  iterations. 

b.  The  Decision  Box  parameter  used  is  the  probability  (in 
percent)  of  a  Yes  exit.  The  probability  values  for  up  to  three 
iterative  entries  are  also  given. 
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2.2.3  Process  Simulation 

The  Simulator  computer  programs  by  which  the  SWAP  Model  is 
mechanized  are  written  in  the  SIMSCRIPT  II. 5  language  for  operation 
on  the  MITRE  Bedford  IBM-370  facility.  The  FY80  design  consisted  of 
four  components  as  follows: 

(1)  The  Data  Input  Processor,  (2)  the  Simulation  Conduct 
Processor,  (3)  the  Output  Report  Generator,  and  (4)  a  Read/Write 
Interface  package  that  serves  to  interface  the  three  processors. 

The  three  processors  execute  sequentially.  The  Data  Input  Processor 
operates  on  the  input  data  sets  defined  in  Appendix  B  to  produce  a 
data  base  usable  by  the  next  processor.  The  second  (the  Simulation 
Conduct  Processor)  is  driven  by  these  data  and  develops  simulation 
results  which  it  stores.  The  Output  Report  Generator  statistically 
analyzes,  formats,  and  prints  the  results.  The  designs  of  the  Data 
Input  Processor  and  the  Output  Report  Generator  are  straightforward. 
The  design  of  the  Simulation  Conduct  Processor  is  rather  unusual 
(for  a  simulation  program),  and  thus  worth  brief  discussion  here. 

The  Simulation  Conduct  Processor  is  table-driven.  Thus,  the 
complete  Model  is  defined  by  a  set  of  table  data  such  as  those  given 
in  Appendix  B.  Each  of  the  two-hundred  plus  boxes  included  in  the 
LoSim  Process  Flow  Diagram  of  the  Full-Scale  Development  Phase, 
discussed  in  previous  sections  of  this  report,  is  descibed  by  an 
entry  in  Table  B-l  and  another  entry  in  Table  B-2,  Table  B-3,  or 
Table  9-4.  After  the  Data  Input  Processor  has  reformatted  these 
tables,  the  Simulation  Conduct  Processor  reads  the  data  for  the 
first  box,  takes  actions  which  depend  on  the  box  type  (e.g.. 

Activity  Box,  Decision  Box)  using  the  assigned  parameter  values 
(e.g.,  activity  duration  or  decision  probability),  and  saves  any 
data  needed  to  describe  the  results.  It  then  proceeds  to  each  of 
that  box's  immediate  successor  boxes;  these  are  processed  in 
appropriate  sequence  until  all  boxes  involved  in  the  pass  through 
the  network  have  been  accessed.  Since  the  Simulation  Conduct 
Processor's  path  through  the  network  is  determined  by  Monte  Carlo 
selection  of  alternative  Decision  Box  exits,  a  different  sequence  of 
box  activation  and  results  is  likely  on  each  path.  Thus,  the 
program  must  repeat  many  times  (per  another  input  parameter)  to 
obtain  statistically  significant  results. 

A  new  program  component,  the  Generic  Adaptation  Processor  (GAP) 
was  added  during  FY81.  The  GAP  is  described  in  Paragraph  3.3. l.e. 


SECTION  3 


ACCOMPLISHMENTS  AND  STATUS 


During  FY81  the  project  budget  provided  for  less  than  two  man 
years  of  staff  effort.  This  effort  was  primarily  directed  at  the 
Simulator  development  activity.  These  developmental  activities  did 
impact  the  process  definition  and  quantification  activities  so  that 
supplemental  progress  was  made  in  these  areas. 


3.1  PROCESS  DEFINITION 

The  LoSim  Level  Process  Flow  Diagram,  as  shown  in  Appendix  A, 
defines  the  software  acquisition  process  as  carried  out  by  the  SWAP 
Model.  During  FY81,  the  following  modifications  were  incorporated: 

a.  Personnel  Boxes  (P-Boxes)  were  added  to  establish  and 
adjust  the  level  of  personnel  available  to  man  the  project  during 
the  developmental  period. 

b.  Remote  Action  Boxes  (R-Boxes)  were  added  to  allow  recurring 
and  ongoing  activities  to  be  terminated  at  appropriate  times. 

c.  A  number  of  changes  in  the  activity  sequences  were 
introduced  to  obtain  a  more  uniform  rate  of  personnel  usage;  these 
sequences  are  considered  to  be  a  better  reflection  of  industrial 
practices . 

d.  The  diagrams  were  selectively  simplified  by  the  aggregation 
of  a  number  of  boxes  representing  elemental  activities  into  fewer 
boxes  with  combined  functions.  Most  of  these  changes  were 
introduced  into  the  concluding  FCA  and  PCA  representations. 


3 . 2  PROCESS  QUANTIFICATION 

The  Box  attribute  quantities  for  the  base  project,  as  shown  in 
the  tables  contained  in  Appendix  B,  were  modified  as  follows: 

a.  A  new  table  (B-S)  was  added  to  control  the  personnel  level 
assigned  to  the  project  via  P-Boxes. 

b.  Table  B-4  was  modified  to  allow  remote  control  parameters 
(via  R-Boxes)  to  be  specified. 
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c.  The  levels  of  personnel  and  time  durations  were  extensively 
modified  as  part  of  the  project  calibration  activity  made  necessary 
by  the  other  changes  introduced  into  the  Model. 

d.  A  technique  for  scaling  the  base  project  tabular  data  into 
data  that  represents  any  target  project  was  defined  and  developed. 
This  capability  is  described  in  Paragraph  3.3. l.e. 


3.3  PROCESS  SIMULATION 

The  Simulator  capabilities  were  extensively  enlarged  and 
revised  as  discussed  below. 


3.3.1  Simulation  Process  Changes 

a.  Personnel  Box  (P-Box)  and  Personnel  Assignment  Strategy 

The  prior  design  imposed  no  limits  on  the  personnel  quantities 
available  on  the  project  being  modeled  so  that  any  box  could  begin 
as  soon  as  all  of  its  logical  precedents  have  been  accomplished. 

The  P-Box  was  introduced  to  establish  and  regulate  the  level  of 
personnel  available  during  the  project.  At  the  same  time,  the  box 
start  logic  was  modified  to  require  the  availability  of  adequate 
personnel  before  a  box  can  begin.  These  changes  caused  major 
manpower  bookkeeping  and  queueing  functions  to  be  developed  and  the 
introduction  of  a  management  strategy  that  mediates  conflicting 
demands  on  limited  manpower. 

b.  Remote  Action  Boxes  (R-Box) 

Certain  activities  such  as  the  Program  Management  Review  (PMR) , 
recur  periodically,  but  eventually  cease  at  some  point  near  the  end 
of  the  project.  Other  activities,  such  as  the  operation  and 
maintenance  of  the  developmental  support  facilities  are  ongoing,  but 
are  shut  down  at  a  point  where  they  are  no  longer  needed.  The  R-box 
was  introduced  to  allow  these  activities  to  be  turned  off  whenever 
the  process  reaches  the  established  point. 

c.  Box  Burst 

Model  0  treats  a  number  of  multiple  parallel  activities  as  if 
each  were  a  single  aggregate  operation.  For  example,  module  coding 
is  represented  by  a  single  box;  it  is  actually  a  collection  of  many 
individual  activities  being  separately  conducted.  This  treatment 
produces  two  unrealistic  consequences: 
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(1)  Individual  activities  can  begin  and  end  at  different 
times,  while  the  aggregate  activity  begins  and  ends  together.  Thus, 
any  successor  box  which  must  normally  wait  till  all  individual 
activities  have  completed,  will  begin  too  soon  in  the  simulation. 

(2)  Individual  activities  can  normally  begin  or  not  in 
response  to  the  level  of  manning  available;  in  contrast,  the 
aggregate  box  needs  the  full  manning  allocated  to  that  box.  When 
project  manning  is  limited,  the  aggregate  box  approach  can 
produce  an  artificial  delay  in  starting  the  box;  this  would  result 
from  the  wait  until  full  manning  becomes  available. 

If  this  problem  were  to  be  solved  by  individually  modeling 
all  modules,  the  Simulator  could  be  swamped  by  excess  detail,  and 
such  detail  would  be  project  specific  rather  than  generic.  The  Box 
burst  solution  was  implemented  to  allow  the  aggregate  boxes  to  be 
given  "burst"  attributes.  Thus,  each  such  box  is  designated  as  a 
"start",  'end",  or  "continue"  burster.  Burst  boxes  automatically 
subdivide  into  "n"  equal  parallel  sub-boxes  with  each  taking  1/n  of 
the  manpower,  and  each  starting  independently.  The  arrangement 
reduced  the  consequences  described  above  by  the  factor  "n",  and 
retains  the  generic  aspect  of  the  process.  In  the  current 
implementation,  "n"  was  set  to  five. 

d.  Data  Input  Checking 

Model  0  accepted  table  input  data  with  only  a  minimum  of 
validity  checks.  Because  the  volume  of  data  is  large  and  manual 
data  entry  is  error  prone  and  the  consequences  of  data  error  can  be 
serious,  the  validity  function  was  expanded.  In  particular,  those 
attributes  thav  could  be  verified  for  consistency,  range  of  value, 
etc. ,  and  which  could  seriously  impact  the  simulation  were  checked 
by  the  data  input  processor.  In  addition,  the  input  table  format 
was  simplified  by  the  removal  of  data  no  longer  needed  by  the 
program;  this  made  table  modification  (e.g.,  adding  or  deleting 
boxes)  much  easier  to  accomplish. 

e.  Generic  Adaptation  Process 

Simulator  Model  0  developed  quantitative  output  data  for  a 
single  mid-range  project.  If  some  other  project  were  to  be 
simulated  using  that  model,  it  would  be  necessary  to  update  all  the 
data  in  over  150  boxes  to  reflect  the  new  project.  This  would 
require  a  very  large  effort: 

(1)  to  determine  correct  data  values  for  each  box, 

(2)  to  physically  enter  the  data,  and 
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(3)  to  detect  and  correct  all  errors  in  the  process. 

Of  these  actions,  step  (1)  is  most  difficult  and  most  uncertain 
in  outcome . 

Model  0  was  never  intended  to  be  adapted  to  other  projects  by 
the  above  method;  it  was  a  stepping  stone  toward  the  more  easily 
adaptable  Simulator,  Model  1.  In  this  year's  Model,  the  adaptation 
to  any  other  (target)  project  has  been  accomplished  by  an  automated 
technique  known  as  the  Generic  Adaptation  Process  or  GAP,  which  is 
documented  in  Appendix  K. 

GAP  is  basically  a  scaling  technique.  It  produces  a  set  of 
seven  scaling  factors  that  are  derived  by  comparing  the  attributes 
of  a  "target"  project  with  those  for  the  "base"  project,  where 
"base"  refers  to  the  mid-range  reference  project  used  for  Model  0. 

The  scaling  factors  developed  are  each  oriented  to  a  specific 
type  of  developmental  activity.  Between  them,  they  account  for  all 
types  of  activities  in  the  acquisition  process,  as  modeled.  Each 
box  in  the  Model  belongs  to  just  one  of  these  factors  and  is  scaled 
by  the  value  obtained  for  that  factor.  The  following  are  the  seven 
activity  scaling  factors  used  by  GAP: 

(1)  Program  Design 

(2)  Program  Coding  through  Integration 

(3)  Program  Test 

(4)  Composite  (or  mixed)  Developmental  Activities 

(5)  Formal  Design  and  Program  Documentation 

(6)  Formal  Test  Documentation 

(7)  Formal  User  Documentation 

The  scaling  process  itself  converts  the  data  values  associated 
with  each  box  in  the  acquisition  network  from  the  box  data  values 
established  for  the  "base"  project  into  data  that  reflects  the 
"target"  project.  The  scaling  relationships  are  not  strictly  linear 
or  just  multiplicative.  They  end  up  altering:  Activity  Box  manning 
levels  and  duration;  Decision  Box  probability;  and  project  staffing 
levels.  They  take  into  account  the  overall  size  of  the  project  and 
the  managerial  policy  that  determines  whether  manning  levels  will  be 
lean  or  heavy  (e.g.,  to  compress  schedule).  It  also  accounts 
differently  for  highly  integrated  activities  as  compared  to  those 
activities  that  can  proceed  relatively  independently. 

The  values  obtained  for  the  seven  factors  are  derived  from  a 
comparison  of  the  attributes  of  the  target  project  against  those  for 
the  base  project.  A  total  of  about  50  attributes  are  considered, 


26 


v.r « 


each  of  which  can  affect  the  value  of  one  or  more  of  the  seven 
scaling  factors.  The  attributes  for  the  base  project  are  used  to 
compute  the  seven  effort  levels  for  the  base  project.  Corresponding 
values  are  computed  for  any  target  project  being  simulated.  The 
ratios  of  these  two  groups  of  effort  levels  produce  the  seven  effort 
factors . 

All  projects  on  which  this  Model  is  used  will  be  compared  in 
terms  of  about  50  attributes,  each  of  which  can  influence  the  cost 
or  schedule  of  the  acquisition.  These  attributes  are  organized  into 
four  groups  as  follows: 

(1)  PRODUCT  -  These  encompass  requirements  and  characteristics 
associated  with  the  products  to  be  developed  and  delivered.  These 
can  be  defined  at  the  CPCI  level;  some  can  be  further  subdivided  to 
the  functional  component  (CPC)  level.  Product  attributes  include 
the  size  and  complexity  of  the  computer  program,  formal 
documentation  requirements  for  both  product  maintenance  and  test, 
and  any  special  test  requirements. 

(2)  METHODS  -  These  characterize  the  methods  and  tools  to  be 
used  by  the  contractor  for  the  design,  programming,  and  test  of  the 
computer  programs . 

(3)  STAFF  -  These  characterize  the  productivity  to  be  expected 
from  each  of  the  different  types  of  personnel  (i.e.,  Designer, 
Programmers,  and  Testers)  that  will  be  assigned  by  the  contractor. 

(A)  CONTRACTUAL  -  They  further  subdivide  into  three  categories 
involving  (a)  the  contract  itself,  (b)  the  contracting  agency,  and 
(c)  the  contractor.  Contractual  factors  tend  to  apply  to  the 
acquisition  as  a  whole,  while  the  other  factors  tend  to  apply  to 
specific  major  activities. 

It  should  be  noted  that  the  user  may  not  know  all  the 
attributes  of  his  project  at  a  time  when  he  needs  to  obtain  an 
estimate.  Simulator  Model  1  provides  default  values  (that  reflect 
current  common  practices)  for  any  values  not  supplied  by  the  user, 
so  that  the  Model  can  be  used  with  minimal  input.  Future  versions 
of  the  simulator  will  respond  to  unknown  entries  by  treating  them  as 
instances  of  uncertainty.  This  will  operate  so  that  the  range  of 
variation  in  the  output  forecast  will  be  selectively  increased  for 
each  default  value  used. 

f.  Miscellaneous  Improvements 

Many  of  the  routines  that  constitute  the  Model  0  Simulator  were 
extensively  reworked  to  improve  the  program  structure.  These 
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changes  will  facilitate  the  installation  of  new  prograa  capabilities 
and  allow  maintenance  to  be  performed  without  extensive  dislocation 
and  consequential  trauma.  Although  this  work  on  the  "bottom  side  of 
the  iceberg"  is  not  visible  from  the  outside,  it  was  most  important 
to  the  successful  completion  of  the  above  described  new  capabilities 
and  to  others  yet  to  be  installed. 

3.3.2  Output  Improvements 

a.  Cost  Data  Reporting 

The  Model  0  reports  provided  no  dollar  cost  data;  all  effort 
was  expressed  in  terms  of  man-days.  Model  1  provides  the  following 
cost  data  reporting; 

(1)  The  user  can  enter  the  following  financial  data 

(a)  Base  Year  wage  rates  for  each  personnel  type. 

(b)  Overhead  rate,  G  &  A,  and  Fee. 

(c)  Annual  inflation  rate  with  starting  month. 

(2)  The  "Manpower  Expenditure  Summary"  report  was  expanded 
to  include  Base  Year  cost  data  and  renamed  "Contractual  Expenditure 
Summary;"  see  Figure  J-4. 

(3)  A  new  "Monthly  Expenditure  Profile"  report  was  created 
that  provides  per  month  cost  data  in  a  four  column  format  that 
provides  per  month  and  cumulative  costs  for  both  base  year  and  then 
year  (i.e.,  including  inflation)  labor  rates;  see  Figure  J-7. 

b.  Output  Data  Variability  Format 

Model  0  reports  indicated  the  range  of  variation  in  output  data 
by  providing  mean  values  and  standard  deviations.  For  Model  1 
reports,  the  range  of  variation  is  provided  by  three  entries  for 
each  data  item  reported,  i.e.,  mean,  optimistic,  and  pessimistic 
values.  The  latter  two  are  based  on  run  data  that  was  segregated 
into  groups  that  fall  into  the  best  and  worst  quintiles.  The 
optimistic/pessimistic  thresholds  can  be  set  by  the  user,  to  meet 
his  own  needs. 

Examples  of  this  format  appear  in  the  following  reports: 

(1)  Milestone  Schedule;  see  J-l 

(2)  Contractual  Expenditure  Summary;  see  J-4 

(3)  Monthly  Expenditure  Profile;  see  J-9 
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c.  Activity  Box  Reports 


In  Model  0,  individual  reports  could  be  obtained  for  any 
individual  activity  or  decision  box.  Model  1  provides  an  Activity 
Box  Summary  Report  instead,  which  uses  a  one  line  per  box  format  in 
which  the  most  significant  data  can  be  shown.  The  change  greatly 
increases  the  utility  of  the  data  because  the  compact  format  allows 
box  data  to  be  easily  found  and  readily  compared;  both  from  box  to 
box  and  run  to  run. 

d.  Subnetwork  Reports 

In  Model  0,  any  report  could  be  obtained  for  any  individual 
subnetwork.  In  Model  1,  reports  can  be  had  for  combinations  of 
subnetworks,  as  selected  by  the  user. 

e.  General  Improvements 

The  report  formats  and  detail  content  of  the  reports  were 
modified  to  improve  their  readability  and  utility.  For  example, 
milestone  dates  are  given  now  in  months  and  days,  rather  than 
working  days;  overall  manpower  utilization  is  now  in  man-months 
rather  than  man-days;  subnetwork  reports  include  the  subnetwork  name 
as  well  as  its  number,  etc. 

f.  Calibration  Aids 

The  calibration  activity  requires  that  base  project  activity 
durations,  box  manning  levels,  project  manning,  and  decision 
probabilities  be  such  that  reasonable  schedule,  cost,  and  personnel 
utilizations  are  achieved.  Special  reports  that  document  the  timing 
and  sequence  of  individual  activities  are  needed  along  with  other 
reports  that  show  how  manpower  pool  levels  fluctuate  during  the 
simulation.  Program  additions  that  create  such  reports  were 
implemented  during  FY81. 


3.4  PROGRAM  DESIGN 

The  program  consists  of  four  packages,  each  of  which  is 
individually  run.  These  packages,  are  listed  here  and  described 
briefly  below.  A  more  detailed  description  of  each  of  these 
programs  is  provided  in  Appendix  I. 

1.  Data  Tables  Input  Processor  (DIP)  Program 

2.  Generic  Adaptation  Process  (GAP)  Program 

3.  Simulation  Conduct  Processor  (SCP)  Program 

4.  Output  Report  Generator  (ORG)  Program 


3.4.1  Generic  Adapt at loe  Procaaaor  (GAP) 

This  program  reads  in  up  to  the  approximately  fifty  project 
descriptors  for  the  target  project  and  uses  these  to  assess  the 
magnitude  of  the  various  activities  involved  in  the  software 
acquisition/development  for  that  project.  It  then  transforms  the 
base  project  box  data  values  into  a  set  that  reflects  the  magnitude 
of  the  target  project.  The  GAP  output  data  can  then  be  read  by  DIP 
which  checks  its  validity  and  converts  the  format  into  one  that  is 
compatible  with  SCP. 

3.4.2  Data  Table  Input  Processor  (DIP) 

This  program  reads  in  the  voluminous  data  tables  that  define 
the  target  project.  It  runs  syntax,  format,  and  consistency  checks 
on  the  data,  and  produces  warning  messages  when  errors  are  found. 
Finally,  DIP  produces  a  data  base  that  can  be  used  by  SCP. 

3.4.3  Simulation  Conduct  Processor  (SCP) 

This  program  conducts  the  simulation  of  the  acquisition 
process.  It  enacts  the  process  by  following  the  box  to  box  sequence 
defined  by  the  network  linkage  table  while  using  the  box  parameter 
data  base  established  by  DIP.  It  makes  multiple  passes  through  the 
network  (quantity  of  passes  is  user  specified)  and  retains  the  data 
produced  during  each  pass . 

3.4.4  Output  Report  Generator  (ORG) 

This  program  reads  in  the  results  of  the  SCP  Simulation, 
statistically  reduces  the  data,  and  organizes  it  to  produce  the 
output  reports  requested  by  the  user. 
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SECTION  4 


PROGRAM  OPERATION  AND  DEMONSTRATION 


4.1  PROGRAM  OPERATION 

The  program  is  currently  designed  to  be  operated  from  a  CRT 
Terminal  that  is  tied  into  the  MITRE  System  370  facility,  using  TSO. 
This  user  interface,  while  adequate  for  use  by  programmers  (the 
current  need)  is  not  appropriate  for  use  by  cost  analysts.  A 
"friendly"  interface  is  planned  for  implementation,  see  5.1.1a. 

The  four  programs  that  constitute  the  Simulator  are  described 
in  paragraph  3.5.  While  each  is  designed  for  independent  operation, 
data  dependencies  impose  an  order  of  operation  as  follows: 

(1)  If  any  of  the  Base  input  tables  (per  Appendix  B)  have 
been  altered,  the  DIP  program  is  used  to  validate 
their  format  and  consistency. 

(2)  The  Generic  Adaptation  Processor  (GAP)  is  used  after 
step  1,  or  as  the  first  step,  to  read  in  the  Target 
project  Descriptors  and  to  accordingly  convert  the 
Base  project  box  data  values  to  reflect  the  target 
project. 

(3)  The  DIP  is  then  run  to  obtain  an  SCP- compatible  data 
base. 

(4)  The  Simulation  Conduct  Processor  (SCP)  is  then  used  to 
conduct  the  simulation. 

(5)  Finally,  the  Output  Report  Generator  (ORG)  is  operated 
to  create  the  reports  wanted. 

Each  of  the  programs  has  options  and  overrides  that  allow 
various  alternative  situations  to  be  explored,  without  the  necessity 
of  going  through  the  whole  sequence  each  time.  For  example,  the  SCP 
permits  data  in  certain  boxes  to  be  altered,  or  certain  paths  in  the 
process  to  be  cut-off,  etc.  before  it  is  run. 


4.2  PROGRAM  DEMONSTRATION 

With  all  the  new  capabilities  described  in  Paragraph  3.3 
installed,  the  program  operation  was  demonstrated  to  the  ESD/ACCE 
Project  Sponsor. 
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4.2.1  Demonstration  Projects 

The  program  was  operated  three  tiaMB  as  follows: 

a.  The  Base  Program  was  operated.  This  illustrates 
operation  without  the  use  of  the  GAP  program  and 
provides  a  baseline  representation  against  which  GAP 
operation  could  be  compared. 

b.  A  hypothetical  program  was  formulated  that  was  twice 
the  size  of  the  base  program.  This  project  (labeled 
"X2")  illustrated  how  the  GAP  program  could  transform 
the  base  data  to  simulate  a  larger  project. 

c.  This  case  is  the  same  as  b.  above,  but  with  a  half 
size  program  (labeled 

The  hypothetical  program  characteristics  are  described  in 
Appendix  K. 

4.2.2  Reports  Produced 

A  set  of  reports  were  produced  to  illustrate  the  results 
achieved  in  the  demonstration.  These  reports,  as  listed  in  the 
following  table,  are  provided  in  Appendix  J. 


Project 

Report  Type 

Subnets 

Fig. 

Base 

Milestone  Schedule 

Full 

J-l 

X2 

Milestone  Schedule 

Full 

J-2 

/2 

Milestone  Schedule 

Full 

J-3 

Base 

Contractual  Expenditure  Summary 

Full 

J-4 

X2 

Contractual  Expenditure  Summary 

Full 

J-5 

/2 

Contractual  Expenditure  Summary 

Full 

J-6 

Base 

Contractor  Monthly  Expenditure  Profile 

Full 

J-7 

X2 

Contractor  Monthly  Expenditure  Profile 

Full 

J-8 

/2 

Contractor  Monthly  Expenditure  Profile 

Full 

J-9 

/2 

Milestone  Schedule 

2,3,4 

J-10 

X2 

Contractual  Expenditure  Summary 

2,3,4 

J-ll 

X2 

Activity  Box  Summary  Report 

Full 

J-12 

4.2.3  Discussion 


The  demonstration  was  conducted  to  show  operation  of  the  Model 
1  programs;  it  was  not  intended  as  an  indication  that  the  Model's 
output  data  target  projects  are  correct  or  reasonable.  The  latter 
purpose  was  inappropriate  because  the  base  project  data  and  GAP 
relationships  have  not  yet  been  calibrated.  Nevertheless,  a  number 
of  observations  can  be  made  from  these  reports. 
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a.  While  the  program  sizes  of  the  two  hypothetical  target 
projects  were  twice  and  half  of  the  base  project,  the  seven  effort 
factors  obtained  for  each  project  indicated  much  different  scales. 
This  is  because  the  project  descriptor  sets  assigned  to  the  target 
projects  reflected  more  recent  technologies  than  those  used  on  the 
base  project.  Thus,  implementation  techniques  were  more  productive 
and  the  degree  of  time  and  storage  criticality  was  reduced.  The 
latter  condition  reflects  the  decreasing  hardware  costs  for  storage 
and  computing  power,  which  reduces  the  need  for  criticality.  The 
seven  Activity  Factors  obtained  were  as  follows: 


Project 

Program  Effort 

Ratios 

Documentation  Ratios 

Name 

Des ign 

Program 

Test 

Mixed 

Design 

Test 

User 

X2 

1.53 

1.15 

0.87 

1.18 

1.61 

1.27 

1.18 

/2 

0.32 

0.38 

0.24 

0.31 

0.27 

0.27 

0.22 

The  model  forecasts  resulting  from  these  inputs  were: 

Project  ID  Mean  Manpower  Costs  (loaded)  Project  Duration  to  PCA 

Base  $6 . 89M  30  Months  16  Days 

X2  $8 . 76M  35  Months  12  Days 

/2  $2.68M  24  Months  18  Days 

The  full  schedule  and  cost  breakdowns  and  monthly  summaries  can 
be  obtained  by  inspection  of  the  actual  reports  produced;  see 
Appendix  J.  While  these  results  reflect  the  operation  of  all  the  new 
capabilities  described  in  3.3.1,  it  should  be  noted  that  the 
Personnel  Assignment  effects  (per  para.  3.3.1a)  were  somewhat  muted 
by  the  imposition  of  an  initial  manpower  level  override  that  created 
a  larger  than  normal  manpower  pool.  This  was  done  to  prevent  the 
uncalibrated  personnel  box  values  from  distorting  the  results  of  the 
overall  operation.  Some  rework  in  the  personnel  assignment 
technique,  which  will  facilitate  manpower  level  calibration,  is 
planned  for  FY82;  see  5.1.1b. 

b.  New  Output  Report  Capabilities 

The  new  output  report  capabilities  listed  below  are  described 
in  3.3.2,  and  are  illustrated  in  the  Appendix  J  reports;  see  list  at 
Para.  4.2.2: 

(1)  Cost  Data  is  shown  in  all  "Expenditure"  reports. 

(2)  Output  data  variability  is  shown  in  all  reports  except 
the  "Activity  Box  Summary"  report. 


33 


(3)  Exaapl—  of  coabined  subnetwork  reports  ere  shown  in 
Figur—  J-10  end  J*ll. 

(4)  An  Activity  Box  Suaaery  Report,  which  w—  truncated  to 
reduce  the  nuaber  of  pages,  is  shown  in  Figure  J-12. 
The  version  shown  orders  the  boxes  by  escending  Box 
ID.  The  seae  report,  but  in  the  order  of  ectivity 
start  tiae,  can  also  be  obtained. 
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SECTION  5 


PLANNED  GROWTH 


While  the  Model  is  now  operable,  there  remains  a  number  of 
capabilities  that  need  to  be  implemented  before  it  can  achieve  its 
full  potential.  At  the  anticipated  project  funding  level,  several 
years  of  continuing  development  are  foreseen.  Paragraph  5.1 
describes  the  work  planned  for  FY82,  and  indicates  some  extensions 
to  this  work  planned  for  later  years.  Other  deferred  tasks  are 
identified  in  Paragraph  5.2. 


5.1  PLANNED  FY82  WORK 


5.1.1  Model  2  Simulator  Development 

a.  User  Interface 

Model  1  uses  a  programmer  oriented  technique  for  entering 
project  definition  data  and  operating  the  Model.  An  interface  that 
allows  Cost  Analyst  personnel  to  operate  the  Model  will  be  defined 
and  implemented  on  Model  2.  The  interface  will  provide  directive 
guidance  to  the  user  on  what  information  is  to  be  entered,  its  range 
of  values,  and  any  default  values  substituted  if  the  data  is 
omitted.  In  addition,  the  operation  of  the  Model,  the  imposition  of 
any  desired  overrides  or  other  directive  data,  and  the  selection  of 
the  desired  data  base  will  all  be  simplified  by  a  unified  set  of 
operating  procedures.  Directions  for  operating  the  Model  will  be 
documented. 

b.  Personnel  Assignment  Method. 

In  Model  1,  each  activity  box  (or  a  burst  derived  sub-box) 
requires  a  defined  mix  of  personnel  (e.g.,  1  system  analyst,  3 
designers,  5  programmers,  0  testers,  and  1  support)  in  order  to 
start.  If  all  members  of  this  mix  are  not  currently  available,  the 
box  must  wait.  The  wait  imposed  by  this  rigid  mix  technique  is  not 
representative  of  real  world  practices.  Model  2  will  permit  a  more 
flexible  manning  mix  to  be  used  to  start  any  box,  and  will  adjust 
the  box  duration  to  reflect  the  mix  actually  assigned.  On  future 
models,  ongoing  long  running  activities  may  include  "mid  stream" 
manning  level  adjustments,  if  the  need  develops. 


c.  Box  to  Box  Transition  Timing 


In  the  Model  1  Simulator  the  starting  of  any  box  requires  that 
all  of  its  required  predecessor  boxes  be  fully  completed.  During 
actual  developments,  it  is  often  possible  for  a  successor  activity 
to  begin  before  all  of  its  predecessor  activities  have  fully 
completed.  Model  2  will  include  provision  to  allow  a  box  to  start 
whenever  each  of  its  predecessors  has  reached  its  designated  degree 
of  completion  (e.g.,  75%).  This  technique,  which  permits  overlap  of 
some  sequential  activities  will  allow  realistic  activity  durations 
to  be  compatible  with  a  realistic  overall  schedule. 

d.  Generic  Adaptation  Process  (GAP) 

GAP  program  development  was  completed  in  Model  1  except  for  a 
few  minor  functions.  Simplified  versions  of  these  functions  were 
substituted  in  order  to  have  a  demonstrable  model  at  the  end  of  the 
fiscal  year.  These  functions  will  be  completed  in  Model  2. 

A  second  stage  GAP  development  will  also  be  carried  out  on 
Model  2,  dependent  on  time  availability.  In  this  second  stage,  the 
Model  will  respond  to  user  input  omissions  (e.g.,  project 
determinants  that  are  not  known  to  the  user  at  the  time  that  an 
estimate  is  wanted)  by  increasing  appropriately  the  range  of 
variation  indicated  in  the  Output  Reports.  The  required  Model 
behavior  will  be  defined  in  FY82,  but  the  implementation  will  be 
dependent  on  the  level  of  programming  support  applied  to  the 
project . 

5.1.2  Model  Quantification 

a.  Base  Project  Attributes  and  Tables. 

Any  Base  project  used  to  provide  the  "take-off"  point  from 
which  other  projects  are  extrapolated  should  ideally  be  one  on  which 
good  data  is  available  that  describes: 

(1)  Project  attributes  as  defined  by  GAP 

(2)  Project  activities  performed  as  defined  by  Table  B-l 

(3)  Project  schedule  that  allows  Activity  Box  durations  to 
be  established 

(4)  Project  manning  that  allows  Activity  Box  manning 
levels  and  Personnel  Box  values  to  be  established 


The  407L  Project  used  for  Model  1  and  Model  0,  Is  far  from  this 
ideal.  While  the  project  was  real,  it  was  completed  more  than 
ten  years  ago  and,  therefore,  reflected  old  technology.  Also  little 
recorded  data  was  available  so  that  personnel  remembrances  had  to  be 
used.  Finally,  the  remembered  data  had  been  adjusted  in  order  to 
reflect  more  current  technology  and  the  increased  experience  level 
of  current  developers.  Because  of  these  conditions,  the  Base 
project  is  more  synthetic  than  real. 

While  the  Synthetic  407L  Project  was  a  suitable  base  on  which 
to  develop  the  Simulator,  it  is  not  a  good  starting  point  from  which 
to  extrapolate  future  projects.  For  this  reason,  a  search  will  be 
conducted  to  find  other  projects  that  more  nearly  meet  this  need. 
Once  one  is  selected,  the  project  definition  table  data  values  will 
be  adjusted  to  reflect  the  new  base  project  and  refined  by  the 
calibration  process  until  they  produce  project  forecasts  that 
conform  to  the  results  actually  experienced. 

b.  Generic  Adaptation  Process  (GAP)  Calibration 

The  cost  estimating  relationships  (CERs),  i.e.,  the  effect  of 
the  various  attributes  of  the  software  project  on  development  costs, 
are  not  well  known.  Most  known  information  exists  at  a  high, 
general  level  (macro-CERs)  and  are  usually  based  on  small 
uncontrolled  (historical)  data  samples. 

The  Model  requires  more  explicit  detailed  relationships 
(micro-CERs)  than  those  published  or  otherwise  available.  These 
relationships  can  be  obtained  by  examining  the  involved  processes, 
developing  appropriate  hypotheses,  testing  these,  and  then  adjusting 
them  until  their  aggregated  effects  mirror  the  available  higher 
level  macro-CERs  . 

During  FY82,  the  variously  available  macro-CERs  will  be 
studied  and  compared  in  order  to  establish  initial  concensus 
relationships  that  represent  the  current  state  of  the  art.  These 
will  then  be  used  to  adjust  and  calibrate  the  micro-CERs  installed 
in  the  GAP  program.  With  these  CERs  in  place,  the  Model  should 
begin  to  be  able  to  produce  estimates  that  are  at  least  comparable 
to  those  produced  by  existing  methods.  In  subsequent  years,  as  the 
Model  is  honed  on  current  and  recent  project  data  (fragmentary 
though  it  is),  the  estimates  will  improve.  Finally,  through  use  of 
the  Software  Acquisition  Resource  Expenditure  (SARE)  data  base  and 
actual  experience  in  validating  the  Model,  the  capability  for 
accurate  estimation  should  continue  to  improve. 


5.1.3  Process  Representat ion 

a.  A  comparison  of  the  notation  and  data  definition 
consistancy  used  on  the  Model  vs.  those  used  on  the  Software 
Acquisition  Resource  Expenditure  (SARE)  project,  which  began  in 
FY81,  will  be  completed.  The  Model  terms  and  methods  will  be 
adjusted  to  facilitate  the  use  of  SARE  data  for  Model  calibration 
activities . 

b.  The  process  representation  will  be  modified  as  necessary  to 
reflect  any  findings  obtained  during  the  process  calibration 
activities.  At  the  same  time,  the  representation  level  will  be 
raised  whenever  smaller  activities  are  found  that  can  be 
appropriately  aggregated. 

5.1. A  Pilot  Application 

One  or  more  pilot  applications  of  the  Model  will  be  sought  out 
to  explore  the  mechanics  of  applying  the  Model  to  a  project.  Any 
such  application  during  FY82,  however,  cannot  provide  a  serious 
forecast;  actual  forecasts  cannot  be  provided  until  the  first  level 
of  base  and  generic  calibration  is  completed. 


5.2  BEYOND  FY82  TASKS  PUNNED 

The  following  tasks  are  foreseen  as  necessary  steps  in  bringing 
the  Model  up  to  its  full  potential.  Each  is  very  briefly  described. 


5.2.1  Simulator  Development  and  Refinement 

a.  Cost  Estimating  Relationship  (CER) .  The  refinement  of  CER's 
is  seen  as  an  ongoing  task.  These  will  be  needed  in  response  to: 

(1)  Feedback  from  the  first  applications  of  the  Model  to 
real  projects 

(2)  The  receipt  of  SARE  data 

(3)  The  tracking  of  the  ongoing  improvements  in 
developmental  technology 

(4)  Generating  CERs  that  apply  to  new  applications  for 
embedded  software 


(5)  The  tracking  of  new  acquisition  strategies 


b.  Facility  Utilization  Limitations.  Facilities,  as  used 
here,  refer  to  resources  other  than  project  manpower  that  are  used 
to  support  software  development.  Mainly,  these  include:  the 
computer  faciliies  used  for  activities  such  as  program  compilation 
and  checkout,  master  program  preparation,  input  data  preparation, 
etc.,  and  any  special  test  facilities.  In  order  to  quantify  these 
relationships,  units  of  facility  power  need  to  be  defined  and  the 
units  used  by  each  task  assigned.  The  initial  implementation  will 
let  the  units  be  "available  time",  and  each  task  will  use  an 
assigned  amount  of  time.  Later,  multiple  facilities  that  model 
those  actually  to  be  used  on  the  project  will  be  reflected. 

c.  Resource  Assignment  Strategy.  Ultimately  the  program  will 
attempt  to  "think"  like  a  project  manager  and  handle  problems  of 
manpower/ resource  assignments,  responses  to  contingencies,  product 
quality  decisions,  etc.  The  current  implementation  assigns 
resources  on  a  FIFO  basis;  later,  task  priority  will  be  combined 
with  FIFO.  Subsequently,  manpower  assignment  to  any  task  will 
reflect  the  then  current  supply/demand  relationship.  Finally, 
preemption  will  be  modeled  to  redirect  resources  to  any  task  that 
becomes  (or  may  become)  a  bottle  neck. 

d.  The  Expanded  View  Diagrams  and  Amplification  Notes  that 
were  partially  developed  in  FY79,  need  to  be  completed.  Users  will 
need  these  notes  in  order  to  fully  understand  the  process 
represented  in  the  LoSim  Diagrams. 

e.  The  Acquisition  Process  should  be  compared  against  the 
applicable  MIL  standards,  to  assure  compatability  or  to  explain 
differences . 

f.  CPCI  Interdependence.  The  basic  Model  is  capable  of 
reflecting  CPCI  interdependence  by  combining  all  the  CPCIs  into  one 
run.  The  use  of  this  method  requires  that  the  same  basic  process 
flow  diagrams  be  adapted  ror  each  CPCI,  with  a  different  box  number 
prefix  being  added  for  each  CPCI  so  as  to  avoid  number  duplication. 
The  long  term  use  of  this  approach  is  not  recommended  because  the 
overall  network  representation  could  be  very  large  and  the  resulting 
simulation  conduct  t .re  (and  expense)  costly. 

Later  versions  of  the  Model  would  use  the  mixed  level  modeling 
technique,  so  that  any  desired  CPCI  can  be  run  at  its  low  (or 
detail)  level  while  the  other  interfacing  CPCIs  (or  CIs)  are 
reflected  at  a  high  level.  This  approach  implies  that  each  of  the 
interfacing  CPCIs  will  itself  have  been  run  at  a  low  level  to 
provide  the  quantitative  basis  for  the  higher  level  manifestation. 
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g.  Project  Monitoring  Support.  The  complimentary  roles  to  be 
assigned  to  SARE  and  the  Model  have  not  yet  been  established. 
Tentatively,  it  is  planned  that  SARE  will  evaluate  actual  data  vs. 
that  originally  estimated  (with  the  aid  of  the  Model)  and  point  out 
significant  differences.  Probably  several  sets  of  estimates  will  be 
created  based  on  several  alternative  "corrective  actions"  that  may 
be  proposed  by  the  contractor  or  government. 

h.  Critical  Path  and  Slack  Output.  A  special  program  will  be 
written  to  examine  all  box  start  and  end  times  while  following  the 
network  progression  backwards  from  end  to  start.  This  program  will 
identify  all  boxes  on  the  critical  path.  A  later  program  version 
will  determine  the  amount  of  slack  time  associated  with  each  box. 

i.  Project  Size  via  Functional  Definition.  Model  2  will 
continue  to  be  based  on  program  size  input  data;  this  implies  that  a 
separate  sizing  effort  must  precede  the  use  of  the  SWAP  estimator. 

A  study  is  planned  to  determine  the  feasibility  of  allowing  the  user 
to  substitute  quantitative  functional  descriptions  for  all  common 
components.  Using  this  information,  the  SWAP  Model  will 
automatically  determine  size  and  complexity. 

j.  ECP  Modeling.  A  capability  to  include  ECP  processing  and 
rework  impact  is  planned  for  inclusion  in  the  Model. 

k.  Efficient  and  Extended  Operation.  The  initial  development 
activity  has  been  focused  on  producing  a  working  model  with  minimum 
implementation  cost.  As  the  Model  goes  into  wider  and  more  frequent 
use,  it  will  become  important  to  reduce  the  cost  of  its  operation. 

A  number  of  techniques  will  be  investigated  and  selectively  applied 
for  accomplishing  this  objective. 

As  the  Model  goes  into  widespread  use,  the  need  may  arise  to 
operate  it  on  some  other  facility  than  a  large  IBM  370  mainframe. 
Since  SIMSCRIPT  has  been  implemented  on  a  number  of  other  computers, 
a  transfer  to  such  other  facilities  can  be  accomplished.  If  the 
targeted  facility  does  not  support  SIMSCRIPT,  the  transfer  would 
equire  considerable  effort.  The  amount  of  such  effort  would  be 
determined  by  the  language  used,  as  well  as  other  capabilities  of 
that  facility. 

5.2.2  User  Support 

a.  Pilot  applications  started  in  FY82  will  need  continuing 
support . 
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b.  Once  the  Model  goes  into  routine  use  at  ESD,  support  will 
be  needed  to  provide  advice  for  special  situations,  or  to  design  and 
implement  changes  desired  by  the  users. 

c.  The  Model's  use  as  an  aid  in  training  ESD  personnel  in 
acquisition  management  has  long  been  contemplated.  Support  for  this 
use  will  be  required. 
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SECTION  6 


CONCLUSIONS  AND 
RECOMMENDATIONS 


The  Final  Report  on  this  project  for  FY79  (and  repeated  in 
FY80)  summarizes  the  rationale  for  this  project  in  the  following 
terms : 

"Effective  system  planning  requires  a  reasonably  accurate  means 
for  estimating  the  cost  and  schedule  for  developing  embedded 
software.  This  need  became  manifest  about  twenty  years  ago  when  the 
first  Air  Force  "L"  systems  were  being  acquired.  Since  then,  system 
technology  has  greatly  improved,  enabling  the  feasibility  of  ever 
more  complex  systems.  Software  estimating  and  management,  however, 
remain  rough  procedures  with  outputs  that  lead  more  to  surprises 
than  to  sound  planning. 

"While  the  various  analytic  estimating  techniques  currently 
being  used  do  yield  estimates,  they  have  not  been  able  to  forecast 
or  account  for  the  wide  deviations  in  results  experienced  on  the 
development  of  different  but  "similar"  systems.  Because  of  this 
situation,  work  was  begun  on  a  software  estimating  technique  that  is 
based  on  a  simulation  of  the  acquisition/development  process  rather 
than  just  on  the  product  being  acquired.  Though  more  complex  than 
the  analytical  methods,  this  approach  appeared  to  offer  the  prospect 
of  better  results." 

Those  observations  were  still  applicable  for  FY81. 

During  FY81,  the  just  operable  model  was  strengthened,  extended 
and  exercised  to  a  point  where  most  of  the  capability  needed  to 
support  initial  usage  is  in  place.  During  this  effort,  the  initial 
promise  of  the  concept  remains  undiminished  and  the  many 
applications  for  the  Model  retain  their  promise.  The  success  of  the 
FY81  effort,  coupled  with  the  continuing  need  for  the  product  being 
developed,  reinforces  the  prior  year's  conclusion,  namely: 

"The  results  of  inaccurate  software  estimates  and  dimly 
illuminated  management  decisions  are  manifest  in  the  high  cost  of 
acquiring  embedded  software.  Considering  the  magnitude  of  annual 
Air  Force  expenditures  on  such  software,  improvement  in  the  software 
acquisition  process  provides  considerable  potential  for  cost 
savings.  The  Process  Model  described  in  this  report  offers  such  an 
opportunity.  The  project  cost  is  small,  its  cost  saving  potential 
large,  and  its  risk  modest.  Continuation  of  this  work  is  prudent 
and  recommended." 
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APPENDIX  A 


PROCESS  FLOW  DIAGRAMS 
AND  AMPLIFICATION  NOTES 


This  appendix  incorporates  and  explains  the  detailed  diagrams 
of  the  software-related  activities  and  decisions  typical  during  the 
Full-Scale  Development  Phase  of  the  Major  System  Acquisition  Life 
Cycle  defined  in  AFR  800-2.  As  such,  it  presents  the  results  to 
date  of  the  Process  Definition  work,  discussed  in  Para.  2.1.1. 

First,  Figure  A-l,  Flow  Diagram  Notation,  explains  the  flow 
diagram  conventions.  Table  A-l,  Index  to  Figure  A-2  Connectors  and 
Box  Numbers,  is  provided  to  help  locate  specific  information  in  the 
multi-page  LoSim  flow  diagrams.  Figure  A-2,  Software  Acquisition 
Process  Model  LoSim  Activity  Flow,  depicts  in  over  150  connected 
activities  and  decisions,  the  software-related  functions  of  the 
entire  Full-Scale  Development  Phase.  Table  A-2,  Process  Flow 
Diagram  Amplification  Notes,  provides  comments  on  selected 
activities  and  decisions  depicted  in  Figure  A-2.  Finally,  the 
abbreviations  used  in  this  appendix  are  listed  and  defined. 


The  Process  Flow  Diagrams  contain  three  basic  types  of  element; 
Function  Boxes,  Auxiliary  Elements  and  Lines  of  Flow,  as  follows: 


1.  FUNCTION  BOXES 
1 . 1  Shapes 

■  Rectangles  (i.e.,  Rectangular  Activity 

Boxes)  are  used  only  to  represent 
mainstream  activities  (i.e.,  activities 
of  principal  importance). 


Trapezoidal  Activity  Boxes  are  used  to 
represent  support  activities.  Both 
mainstream  and  support  activities 
consume  time  and  resources. 


A  hexagon  depicts  a  Special  Event  Box. 
Currently  these  are  used  for  two 
functions.  (1)  The  Milestone  Box,  marks 
a  point  and  supplies  a  name  for  use  in 
creating  the  Milestone  schedule. 

(2)  A  Remote  Action  Box  alters  the 
action  of  another  box  at  a  remote 
location. 


A  rhomboid  depicts  each  Decision  Box.  A 
Decision  Box  is  any  procedure  which 
selects  between  two  mutually  exclusive 
exits.  By  convention,  these  include  no 
time  or  resource  expenditures,  which 
are  included  instead  in  preceding 
activities . 


This  shape  represents  a  Personnel  Box. 
Its  purpose  is  to  alter  the  manpower 
levels  assigned  to  the  project. 


Figure  A-l.  Flow  Diagram  Notation 


1 . 2  Labels 


Each  Function  Box  has  a  label,  printed  just  above  the  box. 
Each  label  is  a  one-  or  two-digit  number  suffixed  by  a  letter. 

1.3  Features 


Each  box  may  contain  several  field  designators,  identified  by 
corner  positions  within  the  box  as  shown  by  letters  X,  Y,  Z  and  C, 
as  follows: 

X  -  indicates  Doer;  i.e.,  the  organization  responsible  for  the 
function:  A  =  government  (e.g.,  Air  Force),  C  =  Contractor,  B  = 
Both. 


Y  -  indicates  Integration  Group:  D  =  Developmental  Integration 
Group  (DIG),  T  =  Test  Integration  Group  (TIG),  Blank  =  the  function 
is  not  divided  into  Groups. 

Z  -  indicates  the  level  at  which  the  work  is  conducted:  1  = 
System,  2  =  Segment,  3  =  CPCI,  4  =  CPC  (Computer  Program  Component), 
5  =  lower  level  module. 

C  -  is  present  on  any  Decision  Box  used  as  a  counter. 

2.  AUXILIARY  ELEMENTS 


2. 1  Shapes 

Connectors 

©o  v 


Terminus 

C_ ,  ‘  "  ) 


Used  to  indicate  a  specific  point  in  the 
process  flow.  May  be  used  to  show 
connection  between  physically  separated 
elements  on  flow  diagrams. 

(A  given  label  must  apply  uniquely  to 
only  one  input  point  in  the  process 
flow) .  The  two  shapes  other  than  the 
circle  are  used  to  point  to  a  box  that 
is  to  be  remotely  actuated. 

Used  to  mark  a  start  or  end  point  of  a 
process.  When  labelled  "fin"  it  marks 
the  end  of  the  specific  flow  path. 


Figure  A-l.  Flow  Diagram  Notation  (Continued) 


3. 


Flag 

Do  for 
each  DIG 


LINES  OF  FLOW 


Used  to  annotate  flow  diagrams. 


The  lines  of  flow  have  arrows  to  indicate  direction,  plus  three 
alphabetic  designators,  as  follows: 


T  N/F/S 

l  r  Start.  Logic 

A  =  Logical  "AND"  relationships  (the  input  is 
necessary  to  start  the  box) . 

R  =  Logical  "OR"  relationship  (only  one  of 

these  is  necessary  to  start  a  box;  inputs 
of  other  types  may  also  be  necessary, 
however ) . 

S  =  Start  immediately  (this  input  by  itself 
will  start  a  box). 

I...  — ♦  Progression  Mode  (PM) 

F  =  Normal  forward  progression 

I  =  Iterative  progression 

C  =  Continue  progression  mode  (F  or  I)  of 
predecessor . 

.  -  ■■■  »  Group  Number  Controller 

N  =  No  group  involvement 
D  =  Increment  DIG  number 
T  =  Increment  TIG  number 
G  =  Retain  predecessor's  Group  number. 


Figure  A-l.  Flow  Diagram  Notation  (Concluded) 
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Figure  A-2  (Rev.  2).  Software  Acquisition  Process  Flow  Diagram-LoSim  Level 
Sheet  1-Organization,  Management,  Support 


Software  Acquisition  Process  Flow  Diagram-LoSio  Level 
eet  2-Top  Level  Design  Through  PDR 


Figure  A-2  (Rev.  2).  Software  Acquisition  Process  Flow  Diagram-LoSim  Level 
Sheet  5-Test  Plan/Procedures/Dry  Runs 


Figure  A-2  (Rev.  2).  Software  Acquisition  Process  Flow  Diagram-LoSim  Level 
Sheet  7-Functional  Configuration  Audit  -  FCA 


Sheet  8-Product  Specs/Users  Manuals 


Figure  A-2  (Rev.  2).  Software  Acquisition  Process  Flow  Diagram-LoSim  Level 
Sheet  9-Physical  Configuration  Audit  -  PCA 


Table  A- 2 


PROCESS  FLOW  DIAGRAM  AMPLIFICATION  NOTES 


Note  Fig.  A-2 

No.  Sht .  Box 

1  1  2A 


2  1  4A 


3  1  4C 


Amplification  Notes 

The  assignment  of  key  personnel  at  the 
initiation  of  a  project  is  generally  a  slow 
process.  Each  person  selected  for  a  new 
project  usually  has  an  existing  assignment 
which  must  be  transitioned  to  a  successor; 
the  successor  may  also  need  to  transition 
his  job  to  another,  etc.  Advance  planning 
by  the  contractor  helps  in  the  personnel 
selection  process  but  the  uncertainties 
associated  with  the  award  and  timing  on 
this  contract  (as  well  as  on  other 
contracts  bid)  make  startup  traumatic  event 
that  gets  under  way  slowly. 

Just  the  concept  and  general  approach  to 
the  Developmental  Integration  Group  (DIG) 
(see  Section  2.1.5)  plan  are  established 
here  to  provide  a  basis  for  the  status 
monitoring  and  management  plans.  The 
grouping  of  specific  CPCs  into  DIGs  is 
established  in  Box  6F.  (See  Note  11). 

Note  that  both  4A3  and  4S  support  activity 
4C3  (CPDP  preparation)  even  though  the 
direct  connection  isn't  shown  on  the  LoSim 
diagram.  This  feedback  is  shown  indirectly 
via  the  4S  to  4A  to  4C  connection;  this 
arrangement  will  satisfy  the  precedence 
needs  of  the  Simulator. 

The  System  Engineering  Management  Plan 
(SEMP),  the  Test  and  Evaluation  Management 
Plan  (TEMP),  and  the  Computer  Resources 
Integrated  Support  Plan  (CRISP)  are 
normally  prepared  during  the  system's 
Validation  Phase.  These  plans  usually 
need  updating  in  the  light  of  the  current 
contract  and  contractor.  This  box  covers 
only  those  portions  concerned  with 
software. 
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Table  A-2  (Continued) 


Note  Fig.  A-2 

No.  Sht.  Box 

4  1  4C 


5  1  4S 


6  1  60A 


7  1  62A 


8  1  4G 

4J 
4L 
4M 


Amplification  Notes 

The  Computer  Program  Development  Plan 
(CPDP)  is  generally  addressed  in  the 
contractor's  proposal.  This  activity 
covers  the  rewrite  and  extension  necessary 
before  this  plan  can  be  put  into  effect 
contractually. 

Per  Section  2.1.4  this  activity  provides 
for  the  most  general  case  where  the  program 
and  test  support  facilities  are  not 
identical.,  even  though  some  portions  of  the 
hardware  may  be  shared  for  both  uses. 

A  need  to  build  support  software  will 
significantly  increase  this  activity's 
elapsed  time  over  that  otherwise  required. 
Parameter  values  for  this  activity  must  be 
selected  to  reflect  the  actual  (or 
expected)  contractual  situation. 

Any  non-trivial  special  (i.e.,  not 
specified)  equipment  or  software  which  is 
to  be  used  to  support  Qualification  Testing 
must  be  evaluated  to  assure  that  it  is 
valid  for  its  intended  use.  As  examples,  a 
facility  may  be  needed  to  emulate  a 
non-available  interfacing  component 
(hardware  or  software)  or  to  produce  radar 
returns  representing  a  flying  aircraft, 
etc.  Any  deliverable  test  support 
component  would  not  be  processed  in  these 
boxes  because  its  validity  would  be 
established  in  the  tests  associated  with 
its  acceptance  by  the  government. 

The  management  plans  are  frequently 
resolved  the  first  full-scale  overall 
Program  Management  Review  (PMR),  as  shown. 
Instead,  they  can  be  treated  at  a  separate 
meeting  (if  they  become  urgent  issues),  or 
without  a  meeting  (by  mail  and  phone)  if 
not  controversial;  the  process  parameters 
can  be  adjusted  to  cover  any  expected  case. 


Table  A-2  (Continued) 


Note  Fig.  A-2 

No.  Sht.  Box 

9  1  66B 

66D 
9  80D 


10  2  6A 

6D 


11  2  6F 


12  2  6G 

6H 
61 


13  2  61 


Amplification  Notes 

PMRs  are  generally  conducted  on  a 
periodic  basis  (e.g.,  monthly  or 
bimonthly)  through  the  entire  contractual 
period.  They  are  shown  here  because  the 
preparation  and  conduct  activities  consume 
considerable  manpower  on  an  intermittent 
basis  and  thereby  can  impact  the 
development  process.  Note  that  a  Special 
Event  Box  (80D)  will  cause  the  PMR  activity 
to  stop  at  the  start  of  PCA. 

The  design  and  evaluation  activities  shown 
are  representative  of  those  conducted  on 
many  projects  they  are  not  intended  as  an 
all  inclusive  set.  In  general,  the  overall 
design  is  sampled  at  a  moderate  depth  while 
design  areas  that  are  perceived  to  be 
risky,  difficult,  or  innovative  are  given 
emphas is . 

Here  the  specific  Developmental  Integration 
Groups  (see  Section  2.1.5)  comprising  the 
CPCI  are  defined. 

The  design  activities  conducted  prior  to 
these  boxes  are  global  in  that  they  include 
the  overall  CPCI  at  a  fairly  gross  level. 
They  establish  that  the  overall  system 
concept  is  feasible  and  can  accord  with 
space,  timing,  and  other  restrictions.  In 
these  boxes,  the  capabilities  to  be 
provided  in  each  DIG  (see  Section  2.1.5) 
are  designed  to  a  depth  necessary  to  show 
that  the  approach  for  each  specific 
function  is  feasible. 

Once  the  contractor  establishes  the 
adequacy  of  his  design  (in  box  61)  he  must 
document  it  (using  Product  Specification 
format)  and  submit  it  for  government  review 
and  approval .  This  is  shown  via  connectors 
LE  and  LC  to  Boxes  20A  to  20E  on  Sheet  8  of 
Figure  A-2. 
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Table  A-2  (Concluded) 


Note  Fig.  A-2 

No.  Sht .  Box 

14  2  6M 

8C 
12A 
12J 


15  2  8E 

10F 
12E 
12H 
18H 
18P 
42B 
42L 
42K 
44K 
46N 
48D 


Amplification  Notes 

Even  when  the  PDR  results  (in  Box  8C)  are 
satisfactory,  there  are  generally  a  number 
of  specific  deficiency  areas  noted  during 
the  extensive  review.  These  are  documented 
by  the  contractor  in  the  design  review 
minutes  as  items  which  he  agrees  to 
correct;  Box  6M  makes  provision  for  these 
corrections.  The  references  to  Boxes  12A 
and  12J  indicate  that  this  note  also 
applies  to  the  CDR  results. 

Each  of  the  Decision  Boxes  branches  on  a 
count  rather  than  on  the  basis  of 
probability.  If  the  design  at  these  points 
has  not  been  completed  for  all  the  DIGs, 
this  causes  the  design  process  to  repeat, 
but  on  the  next  DIG;  e.g.,  at  Box  6G.  Note 
that  regardless  of  the  counter,  further 
design  on  the  current  DIG  continues;  e.g., 
by  transfer  to  connector  D. 
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Appendix  A  Abbreviations 


AF 

Air  Force 

ADEQ 

Adequate 

CCB 

Configuration  Control  Board 

CCI&C 

Code,  Compile,  Integrate  &  Check 

CDR 

Critical  Design  Review 

CDRL 

Contract  Data  Requirements  List 

Cl 

Configuration  Item 

CPC 

Computer  Program  Component 

CPCI 

Computer  Program  Configuration  Item 

CPDP 

Computer  Program  Development  Plan 

CPT&E 

Computer  Program  Test  &  Evaluation 

CRISP 

Computer  Resources  Integrated  Support  Plan 

CRIT 

Critical 

CTL 

Control 

DEMO 

Demonstrate 

DESCR 

Description 

DEV 

Develop 

DIG 

Developmental  Integration  Group 

DISCREP 

Discrepancies 

DIST 

Distribute 

DOC 

Document 
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Appendix  A  Abbreviations  (Continued) 


DSGN 

Des ign 

ECP 

Engineering  Change  Proposal 

EVAL 

Evaluate 

FACIL 

Facility 

FCA 

Functional  Configuration  Audit 

FIN 

End  of  this  process  flow  diagram  path 

FQT 

Formal  Qualification  Testing 

FUNC 

Functional 

HIERARCH 

Hierarchial 

HVARE 

Hardware 

I&C 

Integration  and  Checkout 

IMPL 

Implementation 

INFO 

Information 

INTEG 

Integration 

LVL 

Level 

MAINT 

Maintain 

MGMT 

Management 

MGR 

Manager 

MISC 

Miscellaneous 

ORG 

Organization 

PCA 

Physical  Configuration  Audit 

PCKG 

Packaging 
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Appendix  A  Abbreviations  (Concluded) 


PDR 

PRGM 

PMR 

PREP 

PROB 

PROC 

PROD 

PROG 

PROJ 

REQT 

REVAL 

REVW 

SCHED 

SEMP 

S' WARE 

SPEC 

SPRT 

STD 

SYS 

SZ 

TECH 

TEMP 

TIG 


Preliminary  Design  Review 
Program 

Program  Management  Review 

Prepare 

Problem 

Procedure 

Product 

Programming 

Project 

Requirement 

Reevaluation 

Review 

Schedule 

System  Engineering  Management  Plan 

Software 

Specification 

Support 

Standard 

System 

Size 

Technical 

Test  and  Evaluation  Master  Plan 
Test  Integration  Group 


APPENDIX  B 


MODEL  DEFINITION  DATA 


This  appendix  incorporates  and  describes  the  tables  that  define 
the  software  acquisition  process  logic  and  parameter  values  to  the 
Simulator.  These  tables  are  input  via  a  terminal  to  computer  files 
and  may  easily  be  altered.  As  explained  in  Section  3.4.1,  the 
Simulator  reads  these  files,  reformats  the  tables,  and  interprets 
the  revisions  to  develop  simulation  results.  Within  broadly-defined 
limits  the  tables  may  be  modified  to  represent  more  or  less  detail, 
differences  in  process  logic,  or  revised  parameter  values.  Without 
needing  revision  itself,  the  Simulator  will  interpret  the  modified 
tables  and  develop  corresponding  simulation  results. 

Table  B-l,  Software  Acquisition  Process  Model  Network  Linkage, 
is  a  tabular  representation  of  the  entire  LoSim  Process  Flow  Diagram 
(Figure  A-2).  Table  B-2,  Software  Acquisition  Process  Model 
Activity  Box  Parameter  Data,  contains  the  manning  and  duration 
parameter  value  estimates  for  the  activities  depicted  in  the  LoSim 
Process  Flow  Diagram.  Table  B-3,  Software  Acquisition  Process  Model 
Decision  Box  Parameter  Data,  contains  estimates  of  the  decision 
outcome  probabilities  for  all  LoSim  Flow  Diagram  Decision  Boxes 
except  counters.  Table  B-4,  Software  Acquisition  Process  Model 
Counter  &  Special  Event  Box  Parameter  Data,  contains  the  LoSim  Flow 
Diagram  counter  Decision  Box  limits  and  Special  Event  Box  parameters 
so  far  defined.  Table  B-5,  Software  Acquisition  Process  Model 
Personnel  Box  Parameter  Data,  contains  parameters  that  establish  and 
adjust  the  levels  of  personnel  assigned  to  the  project.  Table  B-6, 
Software  Acquisition  Process  Model  Subnetwork  Titles  gives  the  names 
of  the  various  subnetworks,  for  labeling  of  output  reports. 

The  columns  of  these  tables,  and  the  values  that  the  data  in 
each  column  may  legitimately  contain,  are  explained  below. 


1.0  TABLE  B-l 

Table  B-l  represents  the  Process  Model  network.  It  must 
contain  an  entry  for  each  box  in  the  Process  Flow  Diagram  that  it 
represents.  There  is  currently  an  entry  in  Table  B-l  for  every  box 
in  the  LoSim  Process  Flow  Diagram  (Figure  A-2). 

1 . 1  Box  Data 

a.  Box  NAME:  This  is  the  box's  label  (see  Figure  A-l). 


PREVIOUS  PAGE 
IS  BLANK 


A  =  a  mainstream  Activity  Box. 

B  =  a  branching  box  (i.e.,  a  normal  Decision  Box). 

C  =  a  counter  Decision  Box.  This  is  similar  to  a  type  B 
box,  except  that  the  exit  is  determined  by  whether  an 
incrementing  counter  has  reached  its  limit;  see  Table 
A-2 ,  Note  15. 

H  =  a  helping  box  (i.e.,  a  support  Activity  Box).  See 
Figure  A-l. 

M  =  a  Milestone  Box.  This  provides  for  displaying 

Milestones,  at  designated  locations  in  the  process 
f  low . 

P  =  a  Personnel  Box.  This  will  establish  and  adjust 
manpower  assigned  to  the  project. 

R  =  a  Remote  Action  box.  This  box  provides  for  resetting 
counters,  changing  parameter  values,  and  providing  for 
as  yet  undefined  future  needs. 

1 . 2  General  Data 

a.  Transformation  Class  (TRANS .CLASS) 

A  set  of  15  transformation  classes  have  been  established  to 
provide  for  combinations  involving:  Activity  Type,  Documentation, 
and  Growth  Pattern. 

The  classes  are  identified  by  three  letters  "AGD"  as  follows: 

Basic  Activity  (A):  D  =  Design;  P  =  Programming;  T  =  Test;  G  = 
General . 

Growth  Pattern  (G) :  F  =  Fragmented;  I  =  Integrated;  K  =  Constant. 

Documentation  Task  (Dj:  Letter  "D"  identifies  Documentation,  if 
present;  otherwise,  it  is  omitted. 

For  example,  "TFD"  indicates  a  Test  Activity,  with  Fragmented 
Growth,  involving  Documentation. 


Fourteen  of  these  classes  are  derived  as  combinations  of  the 
seven  basic  Activities  (see  3.3. le)  and  two  of  the  Growth  patterns 
(i.e.,  F  &  I).  The  fifteenth  class  includes  all  boxes  that  have 
type  K  (constant)  growth.  This  latter  class  is  provided  to  allow 
any  project  unique  boxes  to  retain  their  assigned  data. 

b.  Doer:  This  defines  the  agency  or  agencies  assigned  to 
perform  the  activity  or  to  make  the  decision. 

A  =  Government  (e.g..  Air  Force) 

C  =  Contractor 

B  =  Both 

N  =  Does  not  apply 

c.  Box  Grp:  This  defines  the  box's  membership  (if  any)  within 
an  Integration  Group  (see  Section  4.1.5). 

D  =  Developmental  Integration  Group  (DIG) 

T  =  Test  Integration  Group  (TIG) 

N  =  No  Integration  Group 

d.  Burst:  This  defines  the  box's  status  as  to  whether  it  is 
a  burst  box  or  not  and  if  it  is,  its  status  within  the  burst  group. 

N  =  non-bursting 

R  =  non-bursting  and  recurrent  (see  3.3.1b) 

S  =  start  of  burst 
C  =  continue  burst 
E  -  end  of  burst 

e.  Subnet:  A  user  may  assign  the  box  to  any  one  of  up  to  15 
Subnetworks  by  entering  a  number  in  the  range  1-15  in  this  column. 
The  Simulator  will  develop  aggregate  timing  and  cost  data  for  each 
Subnetwork  as  well  as  the  entire  network. 


1.3  Successors 


a.  Box:  This  is  the  Box  Name  (see  paragraph  1.1a)  of  the 
successor  box.  If  a  box  has  more  than  one  successor,  the  data  for 
its  second  and  any  subsequent  successors  are  stored  in  corresponding 
columns  of  successive  lines. 

b.  Exit:  This  is  the  box's  exit  used  to  reach  this  successor 

box. 

Y  =  "Yes"  exit  or  single  exit 
N  =  "No"  exit 

R  =  Remote  Activation  Exit 

c.  Group:  The  box's  Group  Control  parameter,  used  to  maintain 
Group  (i.e.,  DIG  or  TIG)  number  continuity  and  incrementation  during 
network  flow. 

N  =  No  group  involvement 

D  *  Increment  DIG  Number 

T  =  Increment  TIG  number 

G  =  Retain  predecessor's  group  number 

d.  Progression  Mode:  A  parameter  used  to  indicate  the 
direction  of  the  box-to-box  progression. 

F  =  Normal  forward  progression 

I  =  Iterative  (i.e.,  backward)  progression 

C  =  Continue  Progression  Mode  of  predecessor 

e.  Start  Logic:  Defines  the  combination  of  predecessors  that 
must  finish  before  this  box  may  start. 

A  =  "AND"  relationship.  This  predecessor's  completion  is  a 
necessary  but  not  a  sufficient  condition  for  starting 
the  box. 

R  =  "OR"  relationship.  Completion  of  only  one  type  R  predecessor  is 
necessary  to  start  the  box.  Predecessors  of  other  types,  if 
specified,  are  also  required. 


S  =  Start  immediately.  This  predecessor's  completion  by  itself  is 
sufficient  to  start  this  box.  All  iterative  progression  uses 
immediate  start. 


2.0  TABLE  B-2 

Table  B-2  contains  the  parameter  data  for  each  Activity  Box 
(box  types  A  &  H)  in  Table  B-l.  Every  Activity  Box  must  have  a 
Table  B-2  entry.  Tables  B-3,  B-4,  B-5  contain  the  parameter  data 
for  the  other  box  types . 


2. 1  Box  Data 

a.  Box  Name:  This  is  the  box's  label,  which  must  be  identical 
to  its  Table  B-l  Box  Name  (see  paragraph  1.1a). 

b.  Box  Type:  This  must  be  the  same  as  the  Table  B-l  entry's 
Box  Type  (see  paragraph  1.1b). 

c.  Box  Group:  Identical  to  the  Table  B-l  entry's  Box  Group 
(see  paragraph  1.2c).  See  note  d.  for  category  F. 

d.  When  box  group  is  set  to  "F",  (used  only  for  Activity 
Boxes),  it  indicates  that  the  box  is  in  a  group  (DIG  or  TIG),  but 
the  activity  duration  on  each  access  if  fixed,  i.e.,  not  altered  to 
reflect  the  quantity  of  DIGs/TIGs. 

2 . 2  Manpower 

Manpower  is  subdivided  into  five  categories  of  work  for 
contractor  personnel,  and  three  for  government  personnel,  as 
explained  below.  Note  that  management  personnel  are  not  assigned  to 
specific  activities.  Instead,  manpower  and  dollar  costs 
representing  a  given  management  structure  are  sustained  for  the 
project  as  a  whole,  or  for  designated  parts  of  it.  Management 
personnel  effort  is  not  shown  for  specific  boxes  even  if  the  work 
is  largely  done  by  such  persons. 

The  table  provides  a  column  to  indicate  quantity  of  persons  (to 
one  decimal  place)  for  each  manpower  category;  i.e.: 

a.  Contractor 

Sys  =  System  engineers  and  analysts 
Dsgn  =  Designers  (junior  and  senior) 
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Prgm  =  Computer  programmers 
Test  =  Software  test  engineers 

Sprt  =  Support  personnel;  e.g.,  writers,  operators, 
maintenance  persons 

b .  Government 

Dev  =  Developing  Command  (e.g.  ESD) 

Usr  =  Using  Command  (e.g.  TAC) 

Sprt  =  Supporting  Command  (e.g.  AFLC) 

c.  Iterate  Factor: 

Many  tasks  may  need  to  be  repeated  because  the  results  achieved 
on  the  first  pass  were  not  adequate  to  meet  subsequent  needs  or 
review  criteria.  Since  the  work  required  on  subsequent  passes 
usually  involves  fewer  persons,  these  three  columns  each  contain  a 
factor  (from  0  to  10)  representing  the  number  of  tenths  by  which  the 
original  number  of  persons  in  each  of  the  manpower  columns  (as 
specified  for  the  first  pass)  must  be  multiplied  to  obtain  the 
manpower  needed  respectively  on  the  second,  third,  and  fourth  or 
later  iteration  of  the  activity.  If  blank,  the  task  never  requires 
iteration,  or  multiplier  value  is  equivalent  to  10. 

2 . 3  Durations 


a.  Days:  The  first  duration  column  contains  the  mean  duration 
of  the  activity,  in  work  days  to  the  nearest  tenth. 

b.  It  Fctr:  The  next  three  columns  each  contain  a  factor 
(from  0  to  10)  representing  the  number  of  tenths  of  the  first 
iteration's  duration  (i.e.,  days  column)  required  to  complete  the 
second,  third,  and  fourth  or  later  iteration,  respectively;  a  blank 
in  these  columns  is  the  same  as  a  "10."  Some  tasks  have  other 
responses  to  iterative  entry  as  indicated  by  a  negative  digit  as 
follows : 

-2:  This  is  used  to  signal  "impossible"  situations  that,  if 
encountered,  will  cause  the  whole  simulation  run  to  halt. 

-1:  This  condition  is  used  to  indicate  that  certain  network 
paths  are  not  to  be  followed  iteratively.  Any  path  so  entered  is 
automatically  terminated. 
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2.4  Wait 


This  field  may  contain  a  mean  waiting  time  (in  days)  before  the 
activity  may  begin.  The  action  may  begin  only  after  the  wait  period 
has  completed;  the  Wait  itself  starts  after  all  predecessor 
conditions  are  satisfied.  If  blank,  no  Wait  is  required. 

2 . 5  Notes 


This  column  refers  to  the  notes  listed  within  Table  A-2, 
Process  Flow  Diagram  Amplification  Notes. 


3.0  TABLE  B-3 


Each  Table  B-3  entry  contains  the  parameter 
Decision  Box  (box  type  B)  with  an  entry  in  Table 
Decision  Box  in  Table  B-l  must  be  represented  by 


data  for  a  normal 
B-l.  Every  normal 
a  Table  B-3  entry. 


3. 1  Box  Data 

These  fields'  definitions  are  given  in  paragraphs  2.1a-c. 

3.2  Yes  Exit  Probab ^lity 

These  four  columns  contain  the  probabilities  (in  percent)  of 
taking  the  "Yes"  exit  on  the  first  four  iterative  passes  through  the 
Decision  Box;  see  paragraph  2.2c.  The  leftmost  column  provides 
first  pass  probability.  The  rightmost  column  probability  will  be 
used  repeatedly  if  the  box  is  iterated  more  often  than  four  times. 

3.3  Wait 


See  paragraph  2.4. 

3.4  Notes 


See  paragraph  2.5. 


4.0  TABLE  B-4 

This  table  contains  an  entry  for  each  counter  Decision  Box 
(type  C)  each  Special  Event  Box  Milestone  Box  (type  M)  and  each 
Remote  Action  Box  (type  R) .  Every  such  box  must  be  represented  by  a 
Table  B-4  entry. 


4.1  Box  Data 

These  fields'  functions  are  given  in  paragraph  2.1a-c. 

4.2  Type 

Two  types  of  function  have  thus  far  been  allocated  to  Special 
Event  Boxes: 


M  =  Milestone.  The  contents  of  the  Event  Label  coluam  (a 
Milestone  name)  will  be  output  on  schedule  reports  for 
each  Special  Event  Box  entered. 

R  -  Remote  Action.  This  action  applies  to  the  Box  override 
(FO)  field  so  that  a  box  can  be  caused  to  be  skipped 
over,  or  "pinched  off"  or  reset  to  normal.  Only 
"pinch"  (F0=1)  is  currently  used. 

4.3  Event  Label 

This  contains  the  characters  to  be  output  as  the  Milestone  name 
for  a  Milestone-type  Special  Event  Box. 

4.4  Parameter 


This  column  identifies  the  parameter  which  is  to  be  changed  by 
a  reset  (type  R)  Special  Event. 

4 . 5  Notes 


See  paragraph  2.S. 


5.0  TABLE  B-5 

This  table  contains  an  entry  for  each  Personnel  Box  (type  P) 
defined  in  Table  B-l. 


5 . 1  Box  Data 

These  fields'  functions  are  given  in  paragraph  2.1  a-c. 

5.2  Contractor  Personnel 

This  contains  seven  columns,  a  trigger  and  six  manpower 
categories.  If  more  than  one  trigger  is  used,  additional  lines  are 
used. 
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a.  Trigger:  A  parameter  used  to  indicate  the  point (s)  in  the 
process  at  which  the  P-Box  is  activated  to  alter  the  personnel  pool 
levels . 

F  =  this  causes  the  P-Box  to  act  when  the  first  DIG  or  TIG 
enters 

C  =  this  causes  the  P-Box  to  act  when  the  last  DIG  or  TIG 
arrives 

W  =  this  activates  the  P-Box  on  first  entry  for  all  non-DIG 
or  TIG  related  boxes 

b.  Manpower  Categories:  The  type  of  manpower  used. 

Syst  Eng  -  System  engineers  and  analysts 

Dsgn  Eng  =  Design  engineers  (junior  &  senior) 

Pgrm  =  Computer  programmers 

Test  =  Software  test  engineers 

Sprt  =  Support  personnel  -  e.g. ,  writers,  operators, 

maintenance  persons 

Mgmt  =  Management  persons 

6.0  TABLE  B-6 

This  table  identifies  the  subnetworks  by  name  and  number. 

6. 1  Subnet# 

This  is  the  subnetwork  number. 

6.2  Title 

This  is  the  name  given  to  the  subnetwork. 
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SOFTWARE  ACQUISITION  PROCESS  MODEL 
TABLE  6-1 F:  NETWORK  LINKAGE 
MODEL  1  DATA  BOX  BURST 


CS 

09/08/81 
GAP  VERSION 


- BO 

NAME 

TYPE 

1  1 

TRANS 

CLASS 

"GENERAL  DATA - 

DOER  GROUP  BURST 

”  1 

SUB 

NET 

1  ..... 
1 

BOX 

EXIT  GROUP  PROG. 

MODE 

START 

LOGIC 

01V 

P 

GI 

C 

N 

N 

0 

02A 

r 

N 

F 

S 

02A 

A 

GI 

C 

N 

N 

1  0 

04  A 

V 

N 

F 

A 

04S 

Y 

N 

F 

S 

04A 

A 

GID 

c 

N 

N 

1  0 

04C 

Y 

N 

F 

S 

06A 

Y 

N 

F 

A 

06Y 

Y 

N 

F 

s 

53  A 

Y 

N 

F 

s 

Y 

N 

F 

s 

04C 

A 

GIO 

B 

H 

N 

10 

04E 

Y 

N 

C 

s 

04E 

A 

GID 

A 

N 

N 

10 

04G 

Y 

N 

C 

s 

04G 

B 

GIO 

A 

N 

N 

1  0 

04  j 

Y 

N 

F 

s 

04C 

N 

N 

I 

s 

04J 

A 

GIO 

B 

\ 

N 

1  0 

04  L 

Y 

N 

F 

s 

04L 

B 

CIO 

A 

?; 

N 

1  0 

663 

Y 

N 

F 

R 

04M 

N 

N 

I 

s 

04M 

A 

GIO 

c 

,\ 

N 

1  0 

04  J 

Y 

N 

I 

s 

04S 

A 

GID 

c 

r« 

N 

10 

C4A 

Y 

N 

F 

A 

60A 

Y 

N 

F 

s 

62  A 

Y 

N 

F 

A 

60Y 

Y 

N 

F 

s 

06A 

A 

DI 

c 

N 

N 

2 

Y 

N 

C 

s 

06F 

Y 

N 

F 

s 

06D 

A 

DI 

c 

N 

N 

2 

06E 

Y 

N 

C 

s 

06E 

B 

DI 

c 

N 

N 

2 

063 

Y 

N 

F 

A 

C6A 

N 

N 

I 

s 

06Y 

Y 

U 

F 

s 

CoF 

A 

Cl 

c 

N 

N 

2 

06G 

Y 

N 

F 

A 

1  4  A 

Y 

N 

F 

s 

C6G 

A 

c: 

c 

0 

s 

2 

OGH 

Y 

G 

C 

s 

OSH 

A 

o: 

c 

D 

c 

2 

OGI 

Y 

G 

C 

s 

061 

B 

■ji 

c 

D 

c 

2 

204 

Y 

c. 

F 

A 

Co  6 

•\ 

3 

I 

s 

06  J 

Y 

G 

F 

s 

06J 

C 

DI 

c 

D 

E 

2 

DOG 

N 

D 

F 

A 

06t 

M 

d: 

N 

D 

N 

9 

06M 

A 

DI 

c 

0 

N 

2 

OCE 

Y 

G 

F 

S 

1  OA 

Y 

G 

F 

A 

1  or 

Y 

G 

F 

s 

06P 

3 

DI 

B 

0 

N 

9 

06R 

N 

G 

I 

s 

C.Z 

Y 

G 

1 

s 

06R 

A 

DI 

c 

0 

N 

2 

GBA 

Y 

G 

I 

s 

06Y 

P 

DI 

c 

N 

N 

0 

F 

I 


.S 

S 

s 


j 


Table  B-l  (Continued) 

06M  Y 

086  C  01  S  0  N  9  40A  Y 

08Y  P  DI  C  0  NO 


G  F  S 

N  F  A 


10A  A  DF  C  0 

IOC  A  OF  C  0 

10E  8  OF  C  D 

10F  C  GK  C  D 


1 0H  A  01  C  0 

10J  8  01  C  0 

101  A  OF  C  0 

ION  A  OF  C  D 

10V  P  DF  C  D 


S  2  IOC  Y 

C  2  10E  Y 

C  2  10F  Y 

1 0A  N 
C  2  10H  Y 

10A  N 
24A  N 
C  2  10J  Y 

C  2  24A  Y 

10L  N 
C  2  1 0H  Y 

N  2  12A  Y 

N  0 


G  C  S 

G  C  S 

G  F  S 

G  I  S 

G  F  S 

0  F  A 

G  F  R 

G  C  S 

G  F  R 

G  I  S 

G  I  S 

G  I  S 


12A  A  01  B  0 

12C  B  01  A  0 

12E  C  GK  B  0 


12F  M  GK  N  0 

12G  B  01  A  0 


»2H  C  GK  B  D 

12J  A  DF  C  C 


E  9  12C  Y 

N  9  12E  Y 

ION  N 

N  9  12G  Y 

1  2  F  N 

1  2  J  N 

N  9 

N  9  12J  V 

ION  N 

12F  Y 

E  0  26A  Y 

70  A  Y 

N  2  16A  Y 

16B  Y 

16Y  Y 


G  C  S 
G  C  S 
G  1  S 
G  C  S 
G  F  R 
G  F  R 

G  F  R 
G  I  S 
G  F  R 
N  F  A 
NFS 
G  F  A 
G  F  A 
G  F  S 


14A  A  PI  C  N 

14C  A  PF  C  N 


N  3 

N  3 


14C 
1 8C 
1  8  J 


Y 

Y 

Y 


NFS 
N  F  A 

N  F  A 


16A  A  PF  C  0 

168  M  GK  C  0 

16C  A  PF  C  D 

16Y  P  PF  C  0 

18C  A  PF  C  D 

180  A  PF  C  D 

18E  A  PI  C  0 

18F  B  PI  C  0 

1BG  A  PI  C  0 


1 8H  C  GK  C  0 

181  B  PI  C  D 


18J  A  PI  C  0 

IBM  A  PI  C  0 

18  P  C  PI  C  0 


S  3 

N  3 

C  3 

N  0 


C  J 

C  3 

C  3 

N  3 

E  3 


E  3 

N  3 


N  3 

N  3 

N  3 


16C  Y 

18C  Y 


180  Y 

18E  Y 

18H  Y 

18G  Y 

62C  N 

181  Y 

1 8  J  Y 

18R  Y 

18Y  Y 

16A  N 

16B  N 

18M  N 

IBP  Y 

1ST  Y 

1  PF  Y 

18X  Y 

22A  < 

1 8  J  N 


G  F  A 

G  F  A 


G  F  S 
G  F  S 
G  F  S 
G  F  S 
G  I  S 
G  C  S 
G  F  A 
G  F  S 
G  F  S 
0  F  A 
D  F  A 
G  I  S 
G  F  S 
G  F  S 
G  C  S 
G  F  S 
N  I  S 
0  F  A 
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Table  B-l  (Continued) 


440  M  TF  8  N  NS 

44M  8  TF  C  T  E  5  44B  N  0  1 

44K  V  0  F 

44K  C  TF  C  T  N  5  23*  V  N  F 

26*  Y  N  F 

708  Y  N  F 

46*  A  TF  B  T  S  5  46C  Y  G  C 

46C  A  TF  B  T  C  5  46L  Y  G  C 

46N  Y  G  C 

46  L  B  TF  A  T  C  5  46P  N  G  I 

46©  y  G  F 

488  Y  G  F 

46N  C  GK  8  T  E  5  46A  N  T  F 

46P  A  TF  C  T  C  5  46A  Y  G  I 

460  C  GK  B  T  E  S  42M  Y  N  F 

46R  Y  N  F 

46R  A  TI  C  N  N  5  25C  Y  N  C 

46S  A  TI  B  N  N  5  46T  Y  N  C 

46T  B  TI  A  N  N  5  43A  Y  N  F 

46R  N  N  I 

46W  Y  N  F 

28A  Y  N  F 

72A  Y  N  F 

54  A  Y  N  F 

46U  R  GK  C  N  NO  60B  R 

62  B  R 

46W  M  GK  N  N  N  5  46U  Y  N  F 

46Y  P  TF  C  N  NO 

47Y  P  TFD  C  T  E  0 

48A  A  TIO  C  N  N  5  52C  Y  N  C 

52G  Y  N  C 

48B  A  TFO  8  T  C  5  48D  Y  G  F 

47Y  Y  G  F 

460  C  GK  B  T  E  5  4BA  Y  N  F 

48  V  F  TIO  C  N  N  0 

50A  A  TID  C  N  S  6  50C  Y  N  C 

50C  A  TIO  A  N  C  6  50E  Y  N  C 

50E  8  TIO  A  N  C  6  50A  N  N  I 

50H  Y  N  F 

50H  A  TID  C  N  C  6  54A  Y  N  F 

50Y  P  TIO  C  N  N  0 

52C  A  TID  A  N  N  5  52E  Y  N  C 

52E  8  TID  A  N  N  9  52F  Y  N  F 

52H  N  N  I 

52M  Y  N  F 

48  Y  Y  N  F 

52F  M  TID  N  N  N  9 

52G  A  TIO  C  N  N  9  52J  Y  N  C 

52H  A  TID  C  N  N  9  52C  Y  N  I 

52J  8  TIO  A  N  N  9  52F  Y  N  F 

52G  N  N  I 

52M  Y  N  F 

52M  A  TID  B  N  N  9  52P  Y  N  F 

52P  A  TIO  A  N  N  9  52R  Y  N  F 

52R  A  TID  B  N  N  9  52Z  Y  N  F 

S2Z  A  TIO  A  N  N  9  80F  Y  N  F 

82 A  Y  N  F 
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Table  B-l  (Continued) 


B2E 

Y 

N 

r 

B2J 

Y 

N 

r 

S3A 

A 

GK 

8 

N 

N 

0 

54  A 

Y 

N 

F 

S3C 

A 

GK 

B 

N 

N 

0 

54  A 

Y 

N 

F 

54A 

A 

TI 

C 

N 

C 

6 

54  E 

Y 

N 

C 

540 

A 

TI 

c 

N 

C 

6 

54A 

Y 

N 

I 

S4E 

B 

TI 

c 

N 

C 

6 

54  D 

N 

N 

I 

54G 

Y 

N 

F 

54G 

M 

GK 

B 

N 

E 

6 

54H 

Y 

N 

F 

54H 

A 

TI 

B 

N 

S 

6 

54K 

Y 

N 

C 

54K 

B 

TI 

A 

N 

c 

6 

54L 

N 

N 

F 

54M 

Y 

N 

F 

54R 

Y 

N 

F 

54  L 

A 

TI 

C 

N 

c 

6 

54H 

Y 

N 

I 

54M 

B 

TI 

A 

N 

E 

6 

54P 

N 

N 

F 

54T 

Y 

N 

F 

46U 

Y 

N 

F 

54P 

A 

TID 

B 

N 

N 

6 

54Q 

Y 

N 

F 

S4Q 

A 

TI 

B 

N 

N 

6 

54S 

Y 

N 

C 

54R 

M 

GK 

B 

N 

E 

6 

54S 

B 

TI 

A 

N 

N 

6 

54W 

N 

N 

I 

54T 

v 

N 

F 

46U 

Y 

N 

F 

54T 

A 

TIO 

C 

N 

N 

6 

54V 

Y 

N 

C 

54V 

B 

TID 

A 

N 

N 

6 

54T 

N 

N 

I 

54  Y 

Y 

N 

F 

54W 

A 

TI 

c 

N 

N 

6 

540 

Y 

N 

I 

54V 

P 

TI 

c 

N 

N 

0 

60A 

H 

GK 

c 

N 

N 

1  0 

60B 

Y 

N 

F 

16C 

Y 

N 

F 

62A 

Y 

N 

F 

60B 

H 

GK 

c 

N 

R 

10 

60B 

Y 

N 

F 

60Y 

P 

GK 

c 

N 

N 

0 

62A 

H 

GK 

B 

N 

N 

0 

62B 

Y 

N 

F 

1  8  J 

Y 

N 

F 

44  A 

Y 

N 

F 

62Y 

Y 

N 

F 

62B 

H 

GK 

C 

N 

9 

0 

62  B 

Y 

N 

F 

62C 

H 

GK 

c 

D 

N 

0 

18X 

Y 

G 

I 

62Y 

P 

GK 

c 

N 

N 

0 

66B 

A 

GK 

B 

N 

R 

1  0 

66D 

Y 

N 

F 

66D 

A 

GK 

B 

N 

R 

1  0 

668 

Y 

N 

F 

70A 

A 

G1D 

C 

N 

N 

8 

70  B 

Y 

N 

F 

708 

A 

GFD 

C 

N 

N 

8 

TOC 

Y 

N 

C 

70C 

A 

GID 

A 

N 

N 

8 

70E 

Y 

N 

C 

70E 

8 

GID 

A 

N 

N 

8 

72C 

Y 

N 

F 

70B 

N 

N 

I 

72A 

A 

GID 

C 

N 

N 

8 

74A 

Y 

N 

F 

72C 

A 

GID 

c 

N 

N 

8 

72A 

Y 

N 

F 

74A 

A 

GID 

B 

N 

N 

8 

74C 

Y 

N 

C 

74B 

A 

GID 

C 

N 

N 

8 

74A 

Y 

N 

I 

74C 

B 

GID 

A 

N 

N 

8 

80E 

Y 

N 

F 

74  B 

N 

N 

I 
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Table  B-l  (Concluded) 


80A 

A 

OFD 

A 

N 

N 

7 

80J 

Y 

N 

F 

800 

R 

GK 

N 

N 

N 

0 

66B 

R 

80E 

A 

GID 

C 

N 

N 

0 

80  F 

Y 

N 

F 

82A 

Y 

N 

F 

82E 

Y 

N 

F 

82  J 

Y 

N 

F 

eoF 

M 

GK 

N 

N 

N 

9 

80J 

8 

OFO 

A 

N 

N 

7 

80  F 

Y 

N 

F 

80  L 

N 

N 

I 

82A 

Y 

N 

F 

82E 

Y 

N 

F 

82  J 

Y 

N 

F 

SOL 

A 

OFD 

A 

N 

N 

7 

80N 

Y 

N 

I 

SON 

A 

OFO 

C 

N 

N 

7 

BOP 

Y 

N 

I 

BOP 

A 

OFD 

A 

N 

N 

7 

800 

Y 

N 

I 

82A 

A 

DID 

C 

N 

N 

9 

82G 

Y 

N 

F 

82E 

A 

010 

A 

N 

N 

9 

82G 

Y 

N 

F 

82G 

A 

DIO 

B 

N 

N 

9 

82P 

Y 

N 

F 

82J 

A 

01 D 

B 

N 

N 

9 

82P 

Y 

N 

F 

82P 

A 

010 

B 

N 

N 

9 

820 

Y 

N 

C 

820 

A 

DID 

C 

N 

N 

9 

825 

Y 

N 

C 

82S 

A 

DIO 

A 

N 

N 

9 

82T 

Y 

N 

c 

82T 

0 

010 

A 

N 

N 

9 

92V 

Y 

N 

F 

B2P 

N 

N 

I 

82V 

A 

010 

A 

N 

N 

9 

82Z 

Y 

N 

F 

bay 

Y 

N 

F 

82W 

A 

010 

C 

N 

N 

9 

82  X 

Y 

N 

C 

82X 

A 

DIO 

A 

N 

N 

9 

82Y 

Y 

N 

c 

82Y 

B 

DID 

A 

N 

N 

9 

82W 

N 

N 

I 

82Z 

M 

GK 

A 

N 

N 

9 

82W 

Y 

N 

F 

84Y 

P 

GFO 

C 

N 

N 

0 
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*  n 


m  «ioctMa  i- 


ii  ii 
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SOFTWARE  ACQUISITION  PROCESS  MODEL 
TABLE  8-3C:  DECISION  BOX  PARAMETER  DATA 


08/27/81  CS 
9/3/81 
GAP  VERSION 


MODEL  1  DATA 


NAME 

—BOX- 

TYPE 

group' 

! - YES 

1ST 

EXIT 

2ND 

PROBABILITIES 

3RD 

FF. 

WAIT 

NOTES 

04G 

8 

N 

BO 

100 

100 

100 

o 

8 

04  L 

9 

N 

80 

90 

90 

90 

0 

8 

06E 

B 

N 

20 

40 

60 

100 

0 

061 

8 

D 

70 

SO 

100 

100 

0 

12  E. 

06P 

8 

D 

SO 

1  00 

100 

100 

0 

13 

08C 

8 

D 

90 

1  00 

100 

100 

0 

1 0E 

8 

D 

20 

50 

80 

95 

0 

10J 

B 

D 

20 

50 

BC 

95 

0 

12C 

B 

0 

80 

90 

90 

95 

0 

12G 

B 

D 

90 

90 

90 

100 

0 

18F 

B 

0 

95 

100 

100 

100 

0 

181 

a 

D 

00 

05 

15 

70 

0 

20E 

8 

D 

70 

90 

95 

100 

0 

24E 

B 

0 

70 

90 

95 

100 

0 

40E 

8 

N 

50 

80 

90 

100 

0 

42E 

B 

T 

40 

60 

75 

90 

0 

44H 

8 

T 

15 

35 

60 

80 

0 

46L 

B 

T 

15 

40 

60 

80 

0 

46T 

B 

N 

80 

90 

95 

1  00 

0 

50E 

B 

N 

0 

10 

30 

50 

0 

S2E 

B 

N 

70 

80 

100 

100 

0 

S2J 

B 

N 

75 

95 

100 

100 

0 

S4E 

B 

N 

25 

50 

75 

90 

0 

54K 

B 

N 

10 

25 

60 

80 

0 

54M 

B 

N 

35 

100 

100 

100 

0 

54S 

B 

N 

30 

60 

90 

100 

0 

54V 

B 

N 

20 

50 

80 

100 

0 

70E 

8 

N 

50 

70 

90 

100 

0 

74C 

B 

N 

60 

80 

90 

100 

0 

80J 

B 

N 

80 

90 

100 

100 

0 

82T 

8 

N 

75 

80 

90 

100 

0 

82V 

B 

N 

75 

90 

35 

100 

0 
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SOFTWARE  ACQUISITION  PROCESS  MODEL 


4/31/81 


TABLE  B-4:  EVENT  BOXES  PARAMETER  DATA 
(MILESTONE.  COUNTER,  ANO  RE  INITIALIZER  TYPES) 

MODEL  1  OATA 


. - BOX - ! 

NAME  TYPE  GROUP  EVENT  LABEL  PARAMETER 


OBJ  C  0 

06L  M  D  POR 

08E  C  0 

10F  C  D 

12E  C  D 

12F  M  D  COR 

12H  C  0 

16B  M  0  START  COOING 

18H  C  0 

18P  C  0 

18R  M  0  CCI  *  C  END 

18T  M  0  CPCI  T  8  I  END 

42B  C  T 

42L  C  T 

440  M  N  FQT  START 

44K  C  T 

46N  C  T 

46Q  C  T 

46U  R  N  FO  1 

46W  M  N  FQT  -  END 

480  C  T 


52F 

M 

N 

FCA 

54G 

M 

N 

SYS 

54R 

M 

N 

SYS 

800 

R 

N 

80  F 

M 

N 

PC  A 

82Z 

M 

N 

PCA 

-  START 

OT  8  E  START 
OT  8  E  END 

FO  1 

-  START 

-  END 
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SOFTWARE  ACQUISITION  PROCESS  MODEL 
TABLE  B-5:  PERSONNEL  BOX  PARAMETER  DATA 


04/33/81  CS 
1*15  AM 


MODEL  1  DATA 


8/3/81 
CAP  VERSION 


NAME 

-BOX- 

TYPE 

GROUP 

1 

TRIGGER 

-CONTRACTOR 
SYST  OSGN 
ENG  ENG 

PERSQNNEL- 
PGMR  TEST 

SPRT 

MGMT 

1 

01V 

P 

N 

n 

2 

2 

2 

2 

3 

06V 

P 

N 

N 

2 

6 

1 

08V 

P 

D 

F 

2 

5 

5 

1 

10V 

P 

0 

f 

1 

9 

4 

2 

1 

C 

-3 

-4 

1 

16V 

P 

D 

F 

-6 

24 

1 

1 

C 

-1 

-9 

-4 

18V 

P 

D 

F 

2 

6 

C 

-3 

-20 

22Y 

P 

N 

N 

1 

0 

-8 

3 

42V 

P 

N 

N 

4 

46V 

P 

N 

N 

-1 

0 

0 

-1 

47V 

P 

T 

C 

-1 

-1 

0 

-4 

48V 

P 

N 

N 

-2 

0 

-2 

-3 

-1 

50V 

P 

N 

N 

1 

1 

2 

0 

1 

54V 

P 

N 

N 

-1 

-1 

-2 

-3 

-1 

-1 

60V 

P 

N 

N 

1 

2 

3 

1 

3 

1 

62V 

P 

N 

N 

-1 

-2 

-3 

0 

84V 

P 

N 

N 

1 

3 

”3 
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SOFTWARE  ACQUISITION  PROCESS  MODEL 
TABLE  B-6:  SUBNETWORK  TITLES 


MODEL  1 

SUBNET# 


1 

a 

3 

4 

5 

6 

7 

8 
9 

10 


i f. 
4 

i 


DATA 


TITLE 


REQUIREMENTS  DEFINITION 
COMPUTER  PROGRAM  DESIGN 
CODING  THROUGH  CPT4E 
FORMAL  TEST  PREPARATION 
FORMAL  TEST  CONOUCT/REPORT 
SYSTEM  TEST 

PRODUCT  SPECIFICATION  PREP 
USERS'  MANUALS  &  CORL  ITEMS 
FORMAL  REVIEWS  «  AUDITS 
SUPPORT  4  MANAGEMENT 
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APPENDIX  I 


COMPUTER  PROGRAM  DESIGN 


The  designs  of  and  interrelations  between  the  four  packages 
that  constitute  the  SWAP  Simulator  are  described  herein: 

1.  Overall  Program  Operation  and  Data  Flow 

1 . 1  Program  Packages 

The  following  four  packages  constitute  the  SWAP  Simulator: 

a.  GAP  -  Tne  Generic  Adaptation  Processor 

b.  DIP  -  The  Data  Table  Input  Processor 

c.  SCP  -  The  Simulation  Conduct  Processor 

d.  ORG  -  The  Output  Report  Generator 

1 . 2  Operational  Relationship 

While  the  four  packages  each  operate  autonomously,  the  order  of 
operation  is  established  by  the  data  dependencies  shown  in  Figure 
1-1,  Data  Flow  Diagram.  The  following  will  aid  in  the 
interpretation  of  this  diagram: 

a.  The  characteristics  of  the  data  contained  in  each  box  is 
denoted  by  the  vertical  enclosures  used  on  the  boxes,  as  follows: 

(1)  ( _ ]  indicates  data  entered  by  the  user 

(2)  [////]  indicates  output  data  sent  to  the  user 

(3)  ((())]  indicates  data  retained  in  the  data  base 

b.  Horizontal  arrows  indicate  the  data  flow  into  and  out  of 
each  package  Cthe  package  is  denoted  by  its  name  enclosed  by 
asterisks).  These  arrows,  therefore,  show  the  data  transformations 
accomplished  by  the  packages.  Note  that  the  direction  of  flow 
alternates  from  line  to  line. 

c.  Vertical  arrows  denote  the  transfer  of  the  data  base  from 
one  package  to  the  next.  These  transfers  account  for  the  data 
dependencies  that  determine  the  order  of  operation. 


Figure  1-1.  Data  Flow  Diagram 


2 . 1  Overview 


GAP  reads  in  user  entered  data  that  describes  a  (Target) 
project  for  which  an  estimate  is  wanted  and  creates  a  set  of  Tables 
that  quantify  the  process  by  which  that  project  will  be 
accomplished.  The  tables  created  are  identical  in  format  to  a  set 
of  existing  tables  that  defines  a  Base  project;  project  attributes 
and  results  achieved  (i.e.,  schedule  and  cost)  for  the  Base  project 
are  known.  GAP  compares  the  attributes  of  the  Target  project  with 
those  of  the  Base  and  derives  some  critical  ratios  which  it  uses  to 
transform  the  Base  data  tables  into  Target  tables.  This  is 
accomplished  in  a  five  step  process  that  is  detailed  below. 

2 . 2  Program  Details 

In  the  first  step,  GAP  accepts  Target  project  descriptors  from 
the  user  and  creates  seven  Effort  Factors  for  the  Target  project: 
Design,  Programming,  Test,  General,  Program  Documentation,  Test 
Documentation,  and  User  Documentation.  The  Effort  Factors  are 
numeric  representations  of  the  difficulty  and  size  of  the  "Target" 
project  for  different  activity  classes.  Furthermore,  unless  the 
user  specifically  enters  DIG  or  TIG  spreads  (see  para.  2.1.3  of  the 
main  report),  this  step  creates  these  based  on  CPCI  size. 

The  second  step  performs  a  similar  conversion  to  create  the 
Effort  Factors  for  the  Base  project. 

The  third  step  divides  the  Target  project  Effort  Factors  by 
their  respective  "Base"  Effort  Factors  to  produce  ratios  that 
enumerate  the  relative  sizes  of  the  two  projects  for  the  seven  types 
of  activities. 

The  fourth  step  expands  the  seven  ratios  to  distinct  ratios  for 
manpower  and  duration  conversion  of  activity  boxes,  yes  probability 
conversion  of  decision  boxes,  and  manpower  conversion  of  personnel 
boxes.  Each  of  the  seven  ratios  of  the  third  step  creates  two 
ratios--one  for  fragmented  activities  (those  that  easily  allow  more 
manpower  to  be  added)  and  one  for  integrated  activities  (those  that 
can  less  readily  accept  increased  manpower).  The  manpower 
conversion  ratio  is  a  function  of  contractor  manning  availability, 
government  scheduling  urgency,  and  the  ratio  for  the  box's  activity 
class.  The  duration  conversion  ratio  is  also  a  function  of  these 
three,  assuming  that  the  larger  the  project  and  the  more  people  on 
it  the  less  efficient  the  process  becomes.  The  probability  ratio  is 
based  on  a  similar  assumption:  the  larger  the  project,  the  greater 
the  chance  of  iteration,  i.e.,  the  smaller  the  yes -probabi 1 ity . 
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The  fifth  step  creates  Target  project  versions  of  Base  Tables 
B-2,  B-3,  and  B-5,  (see  Appendix  B),  converting  the  Base  values  by 
the  proper  ratio.  This  step  does  not  produce  Target  project  B-l, 
B-4,  and  B-6  tables,  because  they  are  not  changed  by  GAP. 

2 . 3  Program  Structure 

GAP  is  implemented  using  the  group  of  routines  shown  in  Figure 
1-2.  The  figure  gives  the  name  and  function  of  each  routine,  and 
indicates  by  indention  the  hierarchial  relationship  between  the 
rout ines . 


94 


GAP  ROUTINE  NAME 


FUNCTION 


GEN. CON 

DEFINE 


ratios  for  generic  to  target  project 

effort  factors  for  target  and  generic  projects 


BOX . CON 


ratios  for  specific  conversion  per  class 


BOX. VAL 

B2.C0NV 

B2. CONSTANTS. INIT 
B2. PARSE. RECORD 
B3.C0NV 

B3 . PARSE . RECORD 
B5.C0NV 

B5. CONSTANTS. INIT 
B5. PARSE. RECORD 


change  tables 

convert  table  B-2 

establish  columns  of  B-2 

change  values  in  B-2  appropriately 

convert  table  B-3 

change  values  in  B-3  appropriately 
convert  table  B-5 
establish  columns  of  B-5 
changes  values  in  B-5  appropriately 


Figure  1-2.  Generic  Adaptation  Process  (GAP)  Program  Structure 
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The  Data  Table  Input  Process  (DIP)  Package 

3 . 1  Overview 

The  DIP  package  performs  two  principal  functions;  it  validates 
the  format,  syntax  and  data  consistency  of  the  project  definition 
tables  (per  Appendix  B)  and  it  reformats  the  data  to  produce  a  data 
base  that  is  compatible  with  the  SCP  programs.  The  performance  of 
each  of  these  functions  is  detailed  below: 

3 . 2  Program  Details 
3.2.1  Data  Base  Creation 

DIP  creates  the  initial  data  base  by  reading  through  seven 
input  tables  (per  Appendix  B)  and  arranging  the  data  into  a  format 
that  SCP  can  use.  The  data  base  is  in  four  parts:  the  run  header, 
the  pass  header,  the  complete  box  description,  and  the  partial  box 
description.  DIP  writes  only  the  first  three  of  these;  the  partial 
box  information  is  used  only  by  SCP  and  ORG  on  multi-repetition 
s imulations . 

The  run  header  consists  of  system  variables  and  default  values 
for  variables  that  are  used  by  at  least  two  of  the  DIP,  SCP  or  ORG 
packages.  Most  of  these  values  are  determined  in  DIP.  Those  that 
are  not  are  initialized  to  zero,  and  wtll  have  values  assigned  later 
by  SCP. 

The  pass  header  contains  information  that  is  generated  for  each 
repetition,  but  is  not  related  to  any  specific  box.  Because  this 
information  is  not  developed  in  DIP,  the  pass  header  arrays  are  not 
stored,  and  all  unsubscr ipted  data  values  in  the  pass  header  are 
written  as  zero. 

The  complete  box  information  contains  all  box-related  data  for 
each  box.  This  includes  general  box  information  (subnetwork,  group, 
etc.),  predecessors,  successors,  occurrence  and  timing  data  for  each 
DIG/TIG,  sub-box  data  (see  para.  3.3.1c)  for  each  sub-box  of  each 
DIG/TIG,  activity  timing  and  manpower  data  for  each  DIG/TIG  of 
activity  or  helper  boxes,  yes -probabi 1  it ies  of  decision  boxes, 
labels  fo*-  milestone  boxes,  and  triggers  and  manning  level  changes 
of  personnel  boxes. 

DIP  first  gathers  all  system  data  (which  are  shielded  from  the 
user  and  maintained  as  variables  for  program  flexibility)  from  the 
system  input  file  and  initializes  arrays  that  contain  alphabetic 
codes  for  attributes  of  boxes  and  successors.  It  then  reads  DIG/TIG 
spread  information  from  Table  B-0.  Next,  Table  B-6  is  lead  to 
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obtain  the  subnetwork  titles.  Subsequently,  Table  B-l  is  read  to 
determine  the  number  of  boxes  to  create.  DIP  then  re-reads  Table 
B-l,  gathering  the  box  level  information  but  not  the  successor 
information.  After  this,  data  from  Tables  B-3,  B-4,  or  B-5, 
depending  on  each  box's  type,  are  gathered.  Subsequently,  DIP  again 
reads  Table  B-l,  processing  the  successors,  creating  predecessors, 
and  checking  for  progression,  group  control,  ai.d  burst  chain 
membership  errors.  Next,  it  reads  Table  B-2  creating  the  OTD's  for 
all  boxes  and  ATM's  for  activity  and  helper  boxes.  After  this,  the 
data  is  written  to  the  binary  file  for  the  SCP.  Finally,  DIP  prints 
all  the  box  information  it  has  gathered  in  the  format  specified  by 
the  user,  using  the  user's  codes,  not  the  internal  representations. 

3.2.2  Input  Error  Checking 

During  DIP  processing,  error  conditions  are  noted  as  they  are 
found,  while  the  program  continues  processing  the  remaining  data. 
This  reduces  the  number  of  passes  needed  to  perform  input  data 
corrections . 


a.  Error  Response  Categories 


Errors  are  categorized  into  three  classes.  Warning  errors 
(signified  WW)  will  not  cause  any  errors  when  the  simulation  is  run. 
They  signify  corrections  that  are  needed  to  maintain  the  network 
within  more  consistent  rules.  Normal  errors  (signified  XX)  do  not 
prevent  the  simulation  from  running,  but  the  Simulator  may  not 
properly  enact  the  logic  expected  by  the  user.  Changes  are  made 
internally  to  try  to  correct  these  mistakes.  Severe  errors 
(signified  YY)  will  cause  the  simulation  to  stop  processing  in  the 
midst  of  a  run. 

b.  Error  Conditions  Checked 


The  following  conditons  are  checked  for  correctness: 

(1)  DIG  and  TIG  spread  percentages  total  100V, 

(2)  Each  Box  is  described  by  defined  field  designators: 
valid  box  types,  DIG/TIG  participation,  organization 
performing  the  action  (i.o.,  contractor  or 
government),  and  burst  membership; 

(3)  Tables  are  consistent  with  each  other; 


-  boxes  described  in  Tables  B-2,  B-3,  B-4,  or  B-j  are. 
in  Table  B- 1 ; 
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-  boxes  described  in  Table  B-l  appear  in  one  and  only 
one  of  Tables  B-2,  B-3,  B-4,  or  B-5; 

-  group  and  type  designators  match  between  Table  B-l 
and  either  Table  B-2,  B-3,  B-4,  or  B-5; 

(4)  Successor  Data  is  complete  and  consistent; 

-  all  three  network  progression  fields  are  present  and 
correctly  designated; 

-  Box  Group  membership  is  consistent  with  Successor 
Group  labels; 

-  Successor  box  ID  also  appears  as  a  box  entry* 

-  progression  modes  and  start  logic  are  consistent 
with  each  other; 

-  Box  Burst  memberships  and  successor  progression 
inodes  are  consistent  with  each  other; 

(5)  Numeric  values  are  within  prescribed  limits,  e.g. , 
many  cannot  be  negative. 

3.3  DIP  Program  Structure 

DIP  is  implemented  using  the  group  of  routines  shown  in  Figure 
1-3.  The  figure  gives  the  name  and  function  of  each  routine,  and 
indicates  by  indention  the  hierarchial  relationships  between  the 
routines . 
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DIP  ROUTINE  NAME 

FUNCTION 

STARTUP 

initialize  data 

SYS . INPUT 

read  system  variables 

INIT. ARRAYS 

initialize  conversion  arrays 

USER. INPUT 

read  dig/tig  spreads 

R. SUBNET 

read  subnetwork  names 

TABLES 

read  tables 

BOX. COUNT 

count  boxes  in  B-l 

INIT. TABLE. B1 

position  to  top  of  B-l 

BOX. INFO 

read  table  B-l 

OTHER. TABLE. DATA 

read  tables  B-3,  B-4,  B-5 

INIT.TALBE.B1 

position  to  top  of  B-l 

SUC. CREATION 

read  successors  from  B-l 

PROG. CHECK 

check  progression  mode  errors 

GROUP. CHECK 

cbeck  group  membership  errors 

BURST. CHECK 

check  burst  chain  membership  errors 

B2 . PROC 

process  table  B-2 

B2. CONSTANTS. INIT 

establish  columns  of  B-2 

ATM. CREATION 

create  the  ATM  entities 

ERROR. CHECK 

check  for  invalid  values  in  B-2 

MANPOWER . COMPUTATIONS 

read  and  convert  B-2  values 

OTD. CREATION 

create  the  OTD  entities  for  all  boxes 

DISPLAY. TOTALS 

show  number  of  errors 

W. RUN. HEADER 

write  run  header 

W. PASS. HEADER 

write  pass  header 

Wl. BINARY 

write  box  data 

LIST.NET 

if  requested,  list  successors/predecessor 

DUMP. BOXES 

if  requested,  show  all  box  data 

Figure  1-3.  Data  Table  Input  Processor  (DIP)  Program  Structure 
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4.  The  Simulation  Conduct  Processor  (SCP)  Package 
4.1  Overview 

The  SCP,  which  conducts  the  Simulation  of  the  software 
acquisition  process  is  the  only  package  that  takes  advantage  of  the 
simulation  features  of  the  SIMSCRIPT  language.  It  conducts  the 
simulation  by  repeatedly  calling  two  event  routines: 

One  of  these  processes  each  box  when  its  time  occurs,  the  other 
moves  the  process  from  a  completing  box  to  its  successor  boxes.  The 
SCP  conducts  many  passes  through  the  network  gathering  data  on  each 
pass  that  it  saves  for  use  by  the  ORG  package.  The  operator  can 
control  SCP  operation  in  three  ways: 

a.  By  selecting  the  number  of  passes  to  be  conducted. 

b.  By  entering  override  data  that  can  alter  box  and  network 
status;  this  provides  a  means  for  altering  simulation  conditions 
without  the  need  to  rerun  DIP  or  GAP. 


c.  By  requesting  various  types  of  output  that  can  be  used  to 
aid  in  debugging  the  simulation. 

4.2  Program  Details 

4.2.1  Textual  Description 

After  initializing  its  variables,  SCP  reads  user  control  card 
images,  which  can  change  data  that  DIP  has  passed  to  SCP.  Any 
altered  data  is  written  to  the  run  header,  and  then  the  box  data  is 
read.  SCP  then  performs  as  many  simulations  as  requested,  writing 
pass  information  and  the  box  data  to  the  binary  file.  After  the 
first  repetition,  SCP  writes  all  box-related  data  to  the  file  along 
with  general  data  for  the  pass.  After  subsequent  repetitions,  the 
general  pass  data  and  only  the  box  data  that  has  changed  since  the 
first  repetition  are  written.  This  includes  each  box's  OTD  and  BOX 
entities,  and  the  elements  of  the  ATM  in  which  timing  factors  and 
manpower  expended  are  stored. 

The  actual  simulation  is  controlled  by  the  SIMSCRIPT  internal 
timing  facility.  Two  events  can  be  scheduled,  a  BOX.PROC  and  a 
FLOW.  BOX.PROC  simulates  the  start  of  a  task.  Thus,  for  example, 
BOX.PROC  gathers  available  manpower  for  activity  boxes  or  decides 
branches  for  decision  boxes.  Activities  are  put  on  a  wait  queue  if 
their  requested  personnel  are  not  available.  If  adequate  resources 
are  available,  BOX.PROC  assigns  them  to  the  box,  starts  it,  then 
schedules  a  FLOW,  which  corresponds  to  the  end  of  a  task.  FLOW  is 


scheduled  at  a  time  based  on  the  duration  of  the  task.  The  actual 
duration  is  randomized  over  a  normal  curve  using  the  specified 
duration  as  the  mean.  All  non-activity  tasks  have  a  duration  of 
zero. 


FLOW  is  a  three-part  process.  First,  it  releases  manpower 
associated  with  each  completing  activity  box.  Then,  it  schedules  a 
BOX.PROC  for  each  successor  box  that  has  had  its  predecessor  and 
burst  chain  membership  requirements  fulfilled.  Finally,  FLOW 
determines  if  any  activity  boxes  in  the  manpower  wait  queue  can  now 
be  scheduled.  FLOW  and  BOX.PROC  in  turn  call  other  routines  that, 
for  exaisple,  search  the  manpower  wait  queue,  or  calculate  the 
deficit  manpower. 

4.2.2  Diagramatic  Description 

A  diagram  showing  the  complete  logic  of  the  SCP  is  given  in 
Figure  1-4.  The  figure  employs  a  Chapin  Chart  format,  which 
provides  an  excellent  portrayal  of  well  structured  code.  Rules  for 
interpreting  Chapin  Charts  are  provided  in  Figure  1-5;  these  will  be 
needed  by  those  persons  not  familiar  with  that  notation. 

4.3  SCP  Program  Structure 

SCP  is  implemented  using  the  group  of  routines  shown  in  Figure 
1-6.  The  figure  gives  the  name  and  function  of  each  routine,  and 
indicates  by  indention  the  hierarchial  relationships  between  the 
routines . 
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SIMULATION  CONDUCT  PROCESSOR 


« 

INITIALIZE  ARRAYS  AND  ENTITIES 

1  ’•-■-»■« - L  - 

1 

• 

READ  CONTROL  CAROS 

1 

1 

READ  DATABASE  FROM  DIP 

i 

MODIFY  BOXES  AS  REQUESTED 

///  POR  REQUESTED  K'JM&ER  OF  REPETITIONS  (Ok  REQUESTED  REP): 

///! . . . . — 

///!  INITIALIZE  STATISTIC  STORES 

///! . . . 

///!  MODIFY  BOXES  CHANGED  BY  REMOTE  CHANGERS 

///. - - - 

///!  FIND  THE  FIRST  BOX  OF  THE  NETWORK 

///! - 

///!  tt  schedule  a  box.prgc  and  start  simulation 

///! - 

///i  WHEN  SIMULATION  ENOS,  CHECK  THE  MANPOWER  WAIT  QUEUE 
///!  TO  ENSURE  EMPTY,  STOP  IF  NOT •* 

///! - 

///:  WRITE  PASS'S  stats  TO  DATABASE 


BOX. P ROC 

I 


Figure  1-4.  Chapin  Chart  for  Simulation  Conduct  Processor 

Sheet  2 
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process  by  box  type 


ACTIVITY 

l 


I 


IF  OURATION  IS  -1,  PINCH** 


IF  OURATION  IS  >2,  WRITE  ERROR  ANO  STOP** 


DO  ALL 


IF  BOX  IS  ALREAOY  RUNNING  FOR  THIS  ITERATION. 
WRITE  ERROR  ANO  STOP** 


DO  ALL  MANPOWER  TYPES  HAVE  SUFFICENT  MANPOWER  AVAILABLE? 


UPDATE  STATISTICS 

GET  A  RANDOMIZED  DURATION 
ADO  TO  INITIAL  WAIT 
TO  GET  TIME  FOR  FLOW 


SEND  BOX  TO  QUEUE 


COUNTER 


I  YES'' 

! - 

!  TAKE  YES  EXIT 


EACH  AND  EVERT  ITEGRATION  GROUP  COMPLETE? 


TAKE  NO  EXIT 


REMOTE  CHANGER 


I  MODIFY  THE  BOX  REQUESTED  WITH  PROPER  CHANGE 


MILESTONE 

I 


I  IF  NOT  FIRST  ITERATION  ,  PINCH 


Figure  1-4.  Chapin  Chart  for  Simulation  Conduct  Processor 
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DECISION 


PERSONNEL  BOX 


FIRST  ITERATION? 


CORRECT  INTEGRATION  GROUP? 
UPDATE  THE  POOLS  AS  REQUESTED 


IF  POOL  LESS  THAN  0 

WRITE  MESSAGE  AND  STOP** 


UPDATE  STATISTICS 


SEARCH  THE  MANPOWER  WAIT  QUEUE 

AND  START  ANY  BOXES  THAT  NOW  HAVE 
ENOUGH  MANPOWER 


UNKNOWN 

i 


WRITE  MESSAGE  AND  STOP** 


Figure  1-4.  Chapin  Chart  for  Simulation  Conduct  Proccsoor 
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FLOW 


RELEASE  MANPOWER  TO  POOL 


ON  ITERATION  FOR  A  COUNTER  BOX 
AND  SUCCESSOR  IS  TO  INCREMENT  DIG/TIG  NUMBER? 


FIND  SCHEDULING  PRIORXTV  AND  DIG/TIG  NUMBER 
(PERSONNEL  BOXES  HAVE  HIGHER  PRIORITY) 


FOR  EACH  DIG/TIG  OF  SUCCESSOR  THAT  MIGHT  START: 


FOR  EACH  SUCCESSOR  OF  THIS  BOX: 


NO 


SET  COMPLETION  FLAG  FOR  THIS  SUB-BOX 
ALL  PREDS  DONE? 


START  PRED  WAIT  AT  THIS  TIME 
SET  OR  FLAG  IF  'OR1  PRED 
SET  PROPER  'AND'  FLAG 
IF  AND  PRED 


ALL  PREOS  DONE  AND  SUB-BOXES  COMPLETE? 


SET  TIME  FOR  SOX.PROC 
AFTER  INITIAL  WAIT 
SET  END  TIME  FOR  PRED  WAIT 


SUCCESSOR  NOT  BURST? 


SCHEDULE 
BOX. PROC 
FOR  FULL  BOX 


MASK  START 
AND  CONTINUE 
SUB- BOXES 
AS  WAITING 
FOR 

NON-BURST 

INPUT 


CURRENT  80X 
START  OR 
CONTINUE 
BURST? 


SCHEDULE  !  SCHEDULE  ALL! 
BOX. PROC  !  SUB-BOXES 
FOR  SAME  !  FOR  BOX. PROC', 
BOX. PROC! 


HAS  MANPOWER  BEEN  RELEASED? 


SEARCH  THE  OUEUE  AND  SCHEOULE  BOX.PROCS  FOR  ACTIVITIES  j 
THAT  NOW  HAVE  ENOUGH  MANPOWER  I 

WITH  A  PRIORITY  GREATER  THAN  THOSE  JUST  SCHEDULED  j 
BY  FLOW  | 


.„_^u 


Figure  1-4.  Chapin  Chart  for  Simulation  Conduct  Processor 
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This  figure  describes  the  notation  employed  on  the  Chapin 
Charts  used  to  diagram  the  SCP  computer  program.  The  Chapin  Chart 
is  a  structured  flowchart  limited  to  three  basic  elements;  Sequence, 
Selection,  and  Repetition.  The  chart  consists  mainly  of  a  series  of 
rectangles.  Control  flows  sequentially  from  top  to  bottom  among 
rectangles,  and  from  left  to  right  within  rectangles.  The 
rectangles  may  be  of  any  size  and  any  dimension.  Figures  a  and  b 
show  the  sequential  flow  of  control,  with  Figure  a  using  Chapin 
notation,  while  Figure  b  uses  conventional  flow  chart  format,  both 
indicate  identical  logic. 


Figure  a 


Figure  b 


Figure  1*5.  Directions  for  Reading  Chapin  Charts 
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A  loop  is  indicated  by  an  inner  rectangle  marked  off  from  a 
given  rectangle  as  in  Figure  c. 


/  /  / 

/  /  / 

/  /  / 

Figure  c 


A  conditional  transfer,  IF-THEN-ELSE  or  SELECT,  is  denoted  by  a 
rectangle  with  the  test  condition  contained  within,  and  the  lower 
corners  capped  by  a  triangular  mark-off  (see  Figure  d) .  The 
rectangles  below  the  triangles  contain  the  operations  to  be  followed 
should  the  condition  have  the  test  result  given  in  the  triangle. 

The  common  edge  acts  as  a  convergent  exit  collector. 


Figure  d 

Rectangles  that  are  marked  with  an  "&&"  are  subroutine  calls 
that  are  described  in  another  Chapin  chart  block.  A  double  asterisk 
(**)  indicates  a  halt  to  the  processing  in  that  chart;  if  it  is 
accompanied  by  a  "STOP",  the  simulation  will  cease,  abnormally. 


Figure  1-5.  Directions  for  Reading  Chapin  Charts 
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SCP  ROUTINE  NAME 

FUNCTION 

SERVICE  ROUTINES  (called  often  by  MAIN,  B0X.PR0C,  FLOW,  and  MAN. Q. SEARCH) 

SHOW 

display  all  variables  when  abend 

PRT. MAN. STATS  # 

formatted  print  of  manpower  tables 

PRINT. FNET. REPORT  # 

formatted  print  of  manpower  usage  table 

PRNTBOX 

format  print  of  box  entities 

ENDPAGE 

determine  if  end  of  page  for  play-by-play 

CURRENT. MONTH 

determine  which  month  currently  in 

MAIN 

ERROR. INIT 

initialize  error  codes  and  messages 

RUN. SIMS 

do  the  simulations 

R. RUN. HEADER 

read  the  run  header 

CONTROL. CARDS 

accept  control  cards  from  user 

R. PASS. HEADER 

read  the  pass  header 

Rl. BINARY 

read  box  data  from  DIP 

W. RUN. HEADER 

write  run  header  for  ORG 

BOX. LOOKUP 

find  boxes  of  control  cards  to  modify 

MODIFY. BOX 

modify  boxes  according  to  control  cards 

BOX . PROC 

** 

CALC. POOL  # 

calculate  the  final  manpower  pools 

CALC. MGR  # 

calculate  the  final  manager  status 

PRT.  MAN.  STATS 

* 

PRINT.  FNET.  REPORT 

* 

W. PASS. HEADER 

write  this  pass'  header  for  ORG 

Wl. BINARY 

if  first  pass,  write  data  for  ORG 

W2. BINARY 

not  first  pass;  only  write  changed  data 

Figure  1-6.  Simulation  Conduct  Processor  (SCP)  Program  Structure 
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5.  Output  Report  Generator  (ORG)  Package 

5 . 1  Overview 

This  package  gathers  and  statistically  analyzes  the  SCP 
simulation  results  (one  logical  record  for  each  pass)  and  then 
produces  the  output  reports  requested  by  the  user. 

During  the  statistical  analysis,  the  multiple  pass  results  are 
segregated  into  three  sets:  pessimistic,  optimistic,  and  mid-range 
(these  are  termed  the  p/o/m  sets),  which  are  based  on  the  "PCA 
Complete"  milestone  time.  The  passes  are  segregated  on  the  basis  of 
the  mean  time  (TIME)  and  Standard  Deviation  (SIGMA)  for  completing 
all  passes,  as  follows: 

Optimistic  (OPT)  (TIME-M . SIGMA)>OPT> (TIME-2M .SIGMA) 

Pessimistic  (PES)  (TIME+M.SIGMA)<PES<(TIME+2M. SIGMA) 

Mid-Range  (MID)  (TIME-M. SIGMA)<MID<(TIME+M. SIGMA) 

M  is  a  user  selectable  segregation  threshold  that  defaults  to  1. 

Data  outside  the  2M. SIGMA  threshold  is  discarded.  The  user  can 
(optionally)  select  a  different  milestone  for  the  segregation 
variable. 

5.2  Program  Details 

ORG  is  divided  into  three  parts.  The  first  part  determines 
whether  a  repetition  is  optimisitc,  pessimistic,  or  mid-range.  The 
second  part  reads  each  repetition's  data,  summing  all  relevant 
values  to  produce  the  means  that  are  presented  in  the  reports.  The 
third  part  generates  the  reports  requested  by  the  user,  and,  if  not 
already  accomplished  in  the  second  part,  transforms  the  gathered 
sums  into  means. 

The  first  part  of  ORG  reads  the  run  header,  the  pass  header  of 
the  first  repetition,  and  the  complete  box  information.  Then  ORG 
reads  the  box,  DIG/TIG,  and  range  percentage  on  which  to  base  the 
p/o/m  sets.  Next,  it  passes  through  the  entire  database  from  SCP, 
saving  information  needed  to  calculate  the  mean  and  standard 
deviation  of  the  earliest  start  time  of  the  specified  box.  Once 
through  the  database,  ORG  determines  the  p/o/m  set  boundaries  and 
the  repetitions  that  fall  into  each  set. 


Ill 


The  second  part  of  ORG  re-reads  the  data  base  from  the 
beginning  without  creating  entities.  It  then  initializes  the 
elements  in  which  statistical  inforaation  is  kept.  For  each  pass, 
network  and  subnetwork  aanpower  usage,  completion  time,  milestone 
times,  network  manpower  pool  and  deficit,  activity  timing  data,''' and 
personnel  box  start  times  are  summed  in  the  proper  p/o/m  set.  After 
the  entire  data  base  is  read,  each  set's  network  manpower  usage, 
completion  time,  and  milestone  sums  are  converted  into  means. 

The  third  part  of  ORG  produces  the  milestone  report  and  the 
contractual  expenditure  summary  report  for  the  full  network.  ORG 
then  accepts  requests  from  the  user  to  produce  any  of  eight  reports 
either  for  the  full  network,  a  subnetwork,  or  a  combination  of 
subnetworks.  A  report  can  be  requested  more  than  once  if  different 
subnetworks  are  wanted. 

Some  of  the  reports  present  the  p/o/m  sets  on  the  same  page, 
whereas  others  require  three  outputs,  one  each  for  optimistic, 
mid-range,  and  pessimistic  passes.  The  report  formats  are  as 
follows : 

Report 

1)  Contractual  Expenditure  Summary 

2)  Milestone  Schedule 

3)  Mean  Monthly  Manning  Profile 
4a)  Personnel  Box  Summary  Report 
4b)  Mean  Monthly  Personnel  Status 

5)  Activity  Box  Summary  Report --Input  Order 

6)  Activity  Box  Summary  Report--EST  Sort 

7)  Contractor  Monthly  Expenditure  Profile 
8a)  Mean  Monthly  Personnel  Pool 
8b)  Mean  Monthly  Personnel  Deficit 
8c)  Mean  Monthly  Personnel  Surplus 

5.3  ORG  Program  Structure 

ORG  is  implemented  using  the  group  of  routines  shown  in  Figure  1-7. 
The  figure  gives  the  name  and  function  of  each  routine,  and  indicates  by 
indention  the  hierarchial  relationship  between  the  routines. 


P/O/M  Reporting  Format 

single  output 
single  output 
separate  outputs 
not  segregated 
single  output 
not  segregated 
not  segregated 
single  output 
separate  outputs 
separate  outputs 
separate  outputs 
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ORG  ROUTINE  NAME  FUNCTION 


SERVICE  ROUTINES  (called  by  all  print  programs) 


MTH 

DAY 

RPT. HEADER 
RPT.NET. HEADER 
LAST. RPT. HEADER 
NEAT. PRINT 
TITLES 


convert  days  to  months 

determine  days  within  a  month 

report  header  for  3  separate  POM  reports 

print  project  and  page 

report  header  of  one  report  for  all  POM 

print  numbers  in  good  format 

print  columnar  titles 


MAIN 


R. RUN. HEADER  # 

read 

START 

find 

SIGMA. SEARCH 

find 

R. PASS. HEADER  it 

read 

Rl. BINARY  it 

read 

R2. BINARY  it 

read 

R. RUN. HEADER 

* 

R. PASS. HEADER 

* 

Rl. BINARY 

* 

the  run  header 
the  p/o/m  buckets 

sigma;  determine  pass/pom  relationship 

the  pass  header 

the  first  pass'  data 

all  other  pass'  data 


PROFILE 

MAN. BOX 
MBOX . PROF 
ABOX.PROF 
PBOX . PROF 
R2. BINARY 
FINISH. STATS 
READ. COSTS 


gather  box  statistics 
sum  manpower  stats 
sum  milestone  box  stats 
sum  activity  box  stats 
sum  personnel  box  stats 
* 

convert  network  stats  to  means 
accept  costs  from  user 


Figure  1-7.  Output  Report  Generator  (ORG)  Program  Structure 
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ORG 

ROUTINE  NAME 

FUNCTION 

SELECT. PRTS 

get  report  requests  from  user 

READ. LINE 

read  each  user  request 

MILER 

produce  milestone  report 

MILESTONE. SCHEDULE 

milestone  report  for  full  network 

M.HEAD 

print  full  network  headers 

MILE. PRINT  # 

print  milestone  box  data 

SUB. MILE. SCHEDULE 

milestone  report  for  subnetwork 

SM . HEAD 

print  subnetwork  headers 

MILE. PRINT 

* 

MANSUMR 

produce  manpower  summary  report 

INT. MONEY. PRINT 

formatted  dollar  print 

ZERO. DIVISOR 

divide  by  zero  without  abend 

MTHMANR 

produce  monthly  manpower  report 

MCOMBR 

produce  personnel  status  report 

PSUMR 

produce  personnel  box  summary  report 

ASUMR 

produce  activity  box  summary  report 

SORT 

shakersort  for  est  sort 

COSTR 

produce  monthly  cost  report 

MARRAY. REPORTS 

produce  manpower  array  reports 

M. POOL. REPORT 

produce  manpower  pool  report 

M.DEFI. REPORT 

produce  manpower  deficit  report 

M.SURP. REPORT 

produce  manpower  surplus  report 

it 

description  used  below 

* 

already  described  above 

APPENDIX  J 


SWAP  MODEL  OUTPUT  REPORTS 


This  Appendix  contains  copies  of  reports  produced  by  Model  1  of 
the  SWAP  Simulator  that  were  selected  to  illustrate  the  improved 
capabilities  developed  during  this  reporting  year.  The  creation  of 
these  reports  was  shown  to  the  project  sponsor  during  an  informal 
demonstration  of  the  results  achieved  in  FY81. 


Project 

Report  Type 

Subnets 

Fix.  No. 

Base 

Milestone  Schedule 

Full 

J-l 

X2 

Milestone  Schedule 

Full 

J-2 

/2 

Milestone  Schedule 

Full 

J-3 

Base 

Contractual  Expenditure  Summary 

Full 

J-4 

X2 

Contractual  Expenditure  Summary 

Full 

J-5 

/2 

Contractual  Expenditure  Summary 

Full 

J-6 

Base 

Contractor  Monthly  Expenditure  Profile 

Full 

J-7 

X2 

Contractor  Monthly  Expenditure  Profile 

Full 

J-8 

/2 

Contractor  Monthly  Expenditure  Profile 

Full 

J-9 

/2 

Milestone  Schedule 

2,3,4 

J-10 

X2 

Contractual  Expenditure  Summary 

2,3,4 

J-ll 

X2 

Activity  Box  Summary  Report 

Full 

J-12 
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Figure  J-8.  Contractor  Monthly  Expenditure  Profile 
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Figure  J-10.  Milestone  Schedule  -  / 2  Subnets 


Figure  J-ll.  Contractural  Expenditure  Suomary  -  X2  -  Subncto 


Figure  J-12.  Activity  Box  Suaanary  Report 
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APPENDIX  K 


SOFTWARE  ACQUISITION  PROCESS  (SWAP)  MODEL 
GENERIC  ADAPTATION  PROCESS  (GAP) 


This  appendix  describes  the  technique  being  developed  to  permit 
the  SWAP  Model  to  be  used  as  a  management  tool  for  the  general 
support  of  any  ESD  system  acquisition  project  involving  embedded 
software. 

1 .  Concept 

Each  project  requires  that  an  explicit  set  of  contractually 
defined  objects  be  prepared,  validated,  and  delivered.  Because  of 
the  commonality  prescribed  within  the  ESD  System  Acquisition 
process,  most  systems  are  developed  via  the  normal  activity 
sequences  diagramed  and  tabularized  in  the  SWAP  Model.  Despite  this 
expected  commonality,  each  project  will  contain  an  uniqueness  that 
can  be  reflected  as  differences  in  kind  and  in  degree.  The 
treatment  for  each  of  these  types  of  differences  (i.e.,  qualitative 
and  quantitative)  is  introduced  below. 

1.1  Differences  in  Kind  (Qualitative  Uniqueness) 

The  qualitative  description  of  the  acquisition  process  is 
defined  by  the  Base  (or  Generic)  Flow  Diagram  and  also  by  a  Network 
Linkage  Table  (Table  B-l)*  that  is  derived  from  it.  Qualitative 
changes  are  introduced  by  amending  the  Flow  Diagrams  and  Linkage 
Table  to  express  the  special  requirements. 

This  is  done  by  reviewing  the  generic  diagram  to  identify  and 
eliminate  differences  as  follows: 

a.  Any  generic  boxes  that  do  not  apply  to  the  specific 
project  are  eliminated;  e.g. 

(1)  a  product  (or  an  approval)  is  not  required 

(2)  a  process  sequence  is  to  be  replaced  by  a 
different  one. 


*  ''B-n1'  Tables  are  defined  in  Appendix  B. 
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b.  Any  additional  project  activities  are  then  added  to 
the  diagrams .  Each  new  box  sequence  must  be 
appropriately  linked  to  show  its  dependency 
relationship  with  the  other  boxes  on  the  diagram. 

c.  The  Network  Connectivity  Table  (Table  B-l)  is  then  updated 
to  reflect  the  changes  introduced  in  the  diagram. 

d.  Quantitative  data  are  then  estimated  for  each  new  box  and 
the  box  inserted  into  the  appropriate  "B"  table.  Also,  if  the  added 
and  deleted  activities  would  impact  project  manning,  the  appropriate 
P.BOX  data  (Table  B-5)  is  amended  accordingly. 

1.2  Quantitative  Conversion 

The  quantitative  behavior  of  the  Model  is  determined  by 
parameter  values  contained  in  Tables  B-2  through  B-5  for  each  box  in 
the  network.  For  example,  each  activity  box  occupies  time  and 
utilizes  personnel;  the  amounts  are  given  in  Table  B-2.  Similarly, 
each  alternative  path  of  the  process  is  to  be  selected  on  the  basis 
of  probability  values  given  in  Table  B-3. 

Values  of  "duration"  and  "manning  levels"  have  been  assigned  to 
each  activity  box,  and  a  "yes  exit  probability"  assigned  to  each 
decision  box;  these  values  are  based  on  a  mid-range  "base"  project. 
These  values,  which  have  been  exercised  and  refined  to  produce 
"normal"  results,  have  been  prepared  only  for  a  typical  C-cubed 
operating  program.  At  a  future  time,  variations  in  this  basic 
diagram  will  be  produced  to  represent  the  acquisition  of  other  types 
of  programs:  e.g.,  test  support,  compilers,  equipment  diagnostics, 
etc . 


In  order  for  any  other  (target)  CPCI  to  be  simulated,  it  must 
be  described  via  a  set  of  effort  determinant  parameter  values  that 
can  be  compared  with  those  used  for  the  "base"  project.  Based  on 
these  parameter  values,  a  set  of  factors  is  derived  that  converts 
the  base  program  box  parameter  values  into  a  set  that  represents  the 
target  CPCI . 

These  conversion  factors  are  derived  from  user  supplied  project 
attributes  that  are  categorized  below  and  then  explicitly  defined  in 
Section  2. 

a.  The  "target"  program  (PRODUCT)  characteristics, 

b.  The  developmental  methods  and  tools  (METHOD)  to  be 
used  by  the  contractor, 
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c.  The  skill  and  experience  of  the  contractor's  project 
personnel  (STAFF),  and 

d.  The  general  contractual  environment  (CONTRACT). 

All  effort  factors  are  normalized  so  that  unknown  situations 
will  default  to  a  value  of  1.  This  method  allows  an  estimate  to  be 
forecast  on  the  basis  of  as  much  data  is  known.  While  greater 
knowledge  will  produce  more  accurate  estimates,  the  lack  of  some  of 
this  knowledge  will  not  prevent  the  Model  from  being  useful;  default 
substitutions  (on  later  models)  will  result  in  forecasts  that 
indicate  a  wider  range  of  expected  variation. 

The  Generic  Adaptation  Process  (GAP)  involves  the  five  steps 
shown  in  Figure  K-l,  these  are  detailed  in  subsequent  paragraphs. 

2.  Project  Definition  Input  Data 

The  following  data  shall  be  entered  to  the  extent  that  it  is 
known  or  can  be  determined  or  estimated  by  the  user.  Unless 
otherwise  indicated,  a  default  value  of  "one"  will  be  substituted 
for  any  data  not  entered.  For  each  attribute  selected,  the  program 
will  obtain  the  corresponding  factor(s)  shown.  Two  factors  are 
sometimes  used;  one  for  the  "direct",  the  other  for  "after"  effects. 
The  latter  factors,  which  are  labeled  by  an  "AFT"  suffix,  are 
applied  against  subsequent  activities.  For  example,  the  design 
technique  used  will  not  only  influence  the  design  effort,  it  may 
also  exert  a  different  effect  on  the  programming,  test,  and 
documentation  work  that  follows.  These  factors  actually  express 
inverse  productivity  because  they  directly  influence  the  calculation 
of  effort  (man-months).  Thus,  a  lower  number  indicates  higher 
productivity.  If  preferred,  the  user  may  enter  his  own  parameter 
value,  rather  than  take  the  value  that  comes  with  his  selections. 

The  data  labeling  conventions  in  this  document  are  described  in 
Figure  K-2.  Knowledge  of  these  conventions  will  greatly  simplify 
the  task  of  following  the  data  manipulations  described  in  the  later 
sections  of  this  document. 

2.1  Developmental  Product  Data 

2.1.1  CPCI  Level 

a.  Program/Design  Documentation  Requirement:  (PDD)  (DIRECT) 

(1)  Full  Product  Spec  per  Standard  DID  1.00 

(2)  Full  Product  Spec  Content-Contractor  Format  0.85 


(AFT) 


x  x 


"DEFINE"  User  prepared  data  that  defines  the  "Target"  Project  is 
entered. 


"EFFORT"  The  "DEFINE"  Data  is  converted  into  project 

effort  levels  for  each  of  the  principal  activities  and 
for  the  whole.  The  amount  of  uncertainty  in  each  of  the 
effort  levels  is  also  derived  from  the  kinds  of  data 
obtained  via  default. 

"GEN. CON"  The  "EFFORT"  values  obtained  above  are  compared  with  a 
similar  set  obtained  for  the  mid-range  "Base"  project; 
the  result  is  a  set  of  ratios  that  reflect  the  relative 
magnitudes  of  effort  required  between  the  two  projects. 


"BOX. CON"  The  "GEN. CON"  ratios  are  used  to  obtain  values  that  can 
be  used  to  convert  the  "Base"  project  box  parameters 
(timing,  manning,  range  of  variation,  and  probability) 
into  values  that  apply  to  the  "Target"  project. 


"BOX.VAL"  The  box  parameter  "Base"  values  in  Tables  B-2,  B-3,  and 
B-5  are  transformed  into  a  set  that  applies  to  the 
"Target"  project. 


Figure  K-l.  Generic  Transformation  Process  Overview 
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1  j  l. 


(3) 

High  Level  Design  plus  Annotated  Listing 

0.70 

X 

(4) 

Standard  Contractor  Content /Format 

0.50 

X 

(5) 

Annotated  Listing  Only 

0.10 

X 

(6) 

None  Required 

0.00 

X 

b.  Test  Documentation  Requirement  (PTD) 

(.The  "AFT”  factor  applies  to  Test  Conduct) 

(1)  Approval  Formality  (PTD.APRVL) 


a) 

Formal  per  DID-PQT  &  FQT 

1.20 

1.30 

b) 

Formal  per  DID-FQT  only 

1.00 

1.00 

c) 

Formal  FQT  but  with  Buyer  Defined 
supplementary  Tests 

.85 

1.00 

d) 

Contractor  format;  subject  to  Govern¬ 
ment  approval 

.90 

.95 

e) 

Contractor  format;  no  Government  Approval 

.50 

.70 

Detail  Level  for  Procedures  (PTD.DTAIL) 

DIRECT 

AFT 

a) 

Fully  explicit.  Each  input  explicitly 

1.00 

1.00 

defined  in  terms  that  relate  directly 
to  the  entry  device.  All  expected 
outputs  are  similarly  defined. 


b) 

Inputs  are  defined  in  functional  terms; 
actual  outputs  are  evaluated  for 

.75 

1.20 

correctness . 

(3) 

Document  Permanence  (PTD. PERM) 

a) 

Document  used  only  for  formal  test 

1.0 

1.0 

b) 

Document  is  to  be  used  also  for 
ongoing  baseline  testing  during 
Maintenance  Phase 

1.1 

.95 

User 

Documentation  Requirement  (PGD) 

(1) 

Per 

Formal  DID,  Government  Approved 

1.00 

X 

(2) 

Contractor  Format,  Government  Approved 

.70 

X 

(3) 

Contractor  format,  no  approval 

.30 

X 
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For  convenience  in  reference  and  in  programming,  all  data  items 
have  been  labeled  in  accordance  with  the  following  conventions. 

Each  item  may  have  up  to  three  fields:  (1)  a  Prefix,  (2)  an 
Elaborator  that  may  have  up  to  two  syllables,  and  (3)  a  Suffix,  as 
follows: 

PREFIX . ELABORATOR . SUFFIX 

(P)  The  PREFIX  includes  two  or  three  letters  (PI,  P2,  and  P3) 
as  follows: 


(PI)  Data  Type: 

P  =  Product  Input,  M  =  Method  Input,  S  =  Staff  Input, 

C  =  Common  Input,  E  =  Effort  Factor,  G  =  Generic  Ratio, 
B  =  Box  Data  Transformer 


(P2)  Activity  or  Common  factor  SOURCE  identifier 

D  =  Design,  P  =  Programming,  T  =  Test,  G  =  General,  C  * 
Contract 

B  =  Buyer,  M  *  Maker 

(P3)  Documentation  related  if  "D"  is  present;  blank  otherwise. 

(E)  The  ELABORATOR,  which  includes  up  to  5  letters  per 
syllable,  is  an  abbreviation  that  extends  the  meaning  of  the  data; 
e . g . ,  MGMT  =  Management . 

(S)  The  SUFFIX  (AFT)  is  used  only  to  identify  "After-effect" 
factors . 

Some  Examples: 

PTD  =  The  Test  Documentation  Factor  as  derived  from 
"Product"  inputs. 

PTD.DTAIL  =  As  above,  but  denoting  level  of  Detail. 
PTD.DTAIL. AFT  =  As  above,  but  applies  to  After-effect 
i.e.,  the  affect  of  Test  Document  Detail  level  on  Test 
Conduct  effort. 

ED  =  The  Design  Effort  level. 

BG.DUR  =  A  factor  that  transforms  the  Duration  parameter 
on  an  Activity  Box. 


Figure  K-2.  Data  Labeling  Conventions 
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d.  Software  Metrics  Requirement  (PG.SOFTW) 


If  Software  METRIC  requirements  are 
imposed  (e.g.,  Maintainability, 

Reliability,  Quality,  Portability, 

Reusability,  Integrity,  etc.),  the  impact 
should  be  estimated. 

e.  Special  Test  Requirements  (PT.SPECL) 

("DIRECT"  applies  to  test  conduct;  "AFT"  to  Documentation) 

(1)  Load/Capacity  Test  (PT.LOAD) 


j  a.  Fully  specified 

1.15 

1.30 

!  b.  Contractor  Defines 

1.05 

1.10 

2)  Flight  Testing  Required  (PT.FLT) 
i  3)  Site  Testing  (PT.SITE) 

j  I 

1.20 

1.05 

a.  Military  Base 

1.25 

1.05 

b.  Multiple  Sites? 

1.35 

1.10 

f.  Direct  Program  Attributes 

1  The  parameters  listed  below  in  Par. 

2.1.2  may  be 

entered  alternatively  at  the  CPCI  level,  if 
CPC  breakdown  has  not  yet  been  accomplished. 

2.1.2  Computer  Program  Component  (CPC)  Data 

The  following  data,  if  known  or  can  be  reasonably  estimated  at 
the  CPC  level,  should  be  entered.  If  not  adequately  known,  all  or 
some  of  the  parameters  may  be  entered  at  the  CPCI  level  per  par. 
2.1.1.f.  If  any  of  the  data  is  entered  at  the  CPC  level,  the  SIZE 
data  must  also  be  at  that  level. 


If  these  data  are  entered  at  both  the  CPC  and  CPCI  level,  the 
former  will  be  used  by  the  program  for  all  cases  where  it  is 
available.  The  CPCI  level  data  is  then  used  to  fill  in  any  data 
gaps  at  the  CPC  level.  If  neither  data  are  present,  default  data 
are  used. 

a.  Size  (PP. SIZE . IN) :  In  Machine  Oriented  Language  (MOL) 
executable  instructions  (X100):  This  data  is 
mandatory. 


f 

,  i _ 
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b.  Newness  Factor 


(1)  Of  Design:  (PD. NEW)  _ 

(2)  Of  Programming:  (PP.NEW)  _ 

(3)  Of  Test:  (PT.NEV)  _ 

c.  Complexity  Factor 

(1)  Of  Design:  (PD.PLEX)  _ 

(2)  Of  Programming:  (PP.PLEX)  _ 

(3)  Of  Test:  (PT.PLEX)  _ 

d.  Criticality  Factors  (PG.CRIT) 

(1)  Ratio  of  storage  needed  vs.  available  _ 

(PP.STR. RATIO) 

(2)  Ratio  of  Processing  Time  used  vs.  available  _ 

(PP. TIM. RATIO) 

(3)  Reliability  Factor:  (PG.RELY) 

The  importance  attached  to  functional  impairment  or  failure  can 
affect  the  effort  expended  for  implementation  and  test  of  the 
function.  The  first  four  examples  below  provide  guidance  for 
selection  of  an  appropriate  RELR  factor  value  on  a  functional 
basis.  The  last  example  provides  a  more  general  basis  for  earlier 


estimates . 

a.  Life  threatening,  e.g.,  aircraft  collision  1.5 

avoidance 

b.  On-line  control,  e.g.,  aircraft  tracking  and  1 
guidance 

c.  Facility  management,  e.g.,  flight  reservation  .8 

d.  Operator  training  .5 

e.  General  C-cubed  operating  program  1.0 

2.2  Developmental  Methods  Data 


If  a  method  is  to  be  used  that  is  not  listed  below,  the  user 
should  enter  appropriate  values  that  are  estimated  by  comparison 
with  the  values  given.  If  more  than  one  method  is  to  be  used,  an 
equivalent  value  should  be  derived  based  on  the  percentage  of  the 
work  to  be  done  with  each  method. 
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2.2.1  Design  Methodology 


If  more  than  one  will  be  used,  give  percentage  of  each 


Design  Representation  Method  (MD.REPR)  DIRECT  AFT 


a. 

Manual  Flow  Charts 

1.0 

1.0 

b. 

Chapin  Charts 

1.0 

.87 

c. 

Decision  Tables 

.95 

.90 

d. 

HIPO  Diagrams  (Hierarchial  I/O) 

1.05 

.95 

e. 

PDL  (Program  Design  Language) 

.90 

.85 

f . 

FSD  (Functional  Sequence  Diagrams) 

1.10 

.80 

g- 

OSD  (Operational  Sequence  Diagrams) 

1.15 

.75 

h. 

Other 

-  - 

-  - 

2.2.2  Programming  Method  (MP.METH) 

The  direct  method  factor  relates  the  effect  of  Programming  Methods  on 
programmer  productivity,  not  on  the  resulting  software  qualities  such  as 
processing  efficiency,  storage  utilization,  clarity,  ease  of  change,  etc. 
The  "AFTER"  Factor  (.C)  relates  the  impact  of  the  method  on  subsequent 
activities,  e.g.,  test  and  documentation. 

a.  Programming  Language  (MP. LINGO) 

(1)  Basic  Assembler 

(2)  Enhanced  Assembler  (e.g.,  Macros,  Library, 

Data  Definitions,  etc.) 

(3)  FORTRAN 

(4)  PL-1 

(5)  JOVIAL  (J-73) 

(6)  CMS -2 

(7)  PASCAL 

(8)  Ada 

b.  Developmental  Facility  Quality  (MP.FCLTY) 

(Enter  subjective  estimate) 

(1)  Debug  Support  (MP.DBUG) 

(2)  Library  Support  (MP.LIBR) 

(3)  Configuration  Management  Support  (MP.CNFIG) 

(4)  Exercise  Support  (MP.EXRSZ) 

(5)  Capacity  (MP.CAP) 


DIRECT 

AFT 

2.5 

2.5 

1.9 

2.0 

1.3 

1.25 

1.25 

1.25 

1.0 

1.0 

1.05 

1.05 

1.15 

1.0 

1.20 

0.85 

DIRECT 

AFT 
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c.  Machine  Access  Method  (MP.ACCES) 


(1) 

Punch  Card  open  shop  (3  accesses/day) 

1.07 

1.15 

(2) 

Punch  Card  Closed  Shop  (3  hr.  turnaround) 

1.15 

1.2 

(3) 

TSO  Terminals,  batch 

1.0 

1.0 

(4) 

UNIX  Terminals,  batch 

0.95 

0.92 

(5) 

Interactive,  Interpretive  Terminal 

0.8 

1.1 

(6) 

Other  (enter  estimate) 

-- 

-- 

2.2.3  Test  Methods  (MT) 

a.  Availability  of  Facility  (MT. AVAIL) 

(1)  Physical  Access  (MT.ACCES) 

a)  Same  Building  (short  walk) 

b)  Another  Building  (long  walk) 

c)  Must  Drive  to  Facility 

(2)  Capacity  (MT.CAP) 

This  is  a  measure  of  the  utilization  of  the 
total  test  facility  during  peak  test  period. 

a)  Can  get  use  on  day  requested 

b)  Can  get  use  within  2 -hours  of  request 

c)  Must  schedule  a  week  ahead  (i.e.,  test 
priorities  needed) 

(3)  Reliability  (MT.RELY) 

a)  10%  unscheduled  downtime 

b)  5%  unscheduled  downtime 

c)  20%  unscheduled  downtime 

b.  Utility  of  Facility  (MT.UTIL) 

(1)  Input  Ease  (MT. INPUT) 

a)  Manual  preprocessing  of  inputs 

b)  Only  manual  real  time  entry 

c)  Manual  preprocessing  plus  real  time  entry 

d)  Extensive  test  problem  generation  aids 

(2)  Output  Ease  (MT.OUTPT) 


DIRECT 


1.0 

1.04 

1.10 


1.0 

.95 

1.10 


1.0 

.98 

1.05 


1.0 

1.05 

.95 

.80 

DIRECT 


a)  Most  outputs  in  numeric  form  (octal  or  hex)  1.15 

b)  Most  outputs  interpreted  to  meaningful  unit  1.00 

c)  Data  finding  &  extraction  tools  plus  (b)  .95 

d)  Automatic  Analysis  tools  plus  (c)  .92 
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(3)  Operating  Ease  (MT.OPER) 


a)  Easily  operated  by  test  conductors  1.00 

b)  Needs  specially  trained  operator  1.05 

2.2.4  Project  Development  Staging 

a.  Developmental  Integration  Groups  (DIGs) 


(1)  Quantity  (  ):  %  each  (  /  /  ) 

(2)  Default  values 

Size  (MOL  Inst)  Quant.  %  Each 


L.T.  20K  1 
20K-50K  2 
50K-100K  3 
100K-200K  4 
G.T.  200K  5 


100 

60/40 

40/30/30 

30/25/25/20 

25/20/20/20/15 


b.  Test  Integration  Groups  (TIGs) 

(1)  Quantity  (  ):  %  each  (  /  /  / 

(2)  Default  Values 

Size  Quant. 

L.T.  20K  1 

20K-50K  2 

50K-100K  4 

100K-200K  6 

G.T.  200K  8 


X  Each 

100 

60/40 

30/25/25/20/ 
20/20/15/15/15/15 
15/15/15/15/10/10/10/1 0 


2.3  Technical  Staff  Experience  Data 


2.3.1  Designers  (SD) 

2.3.2  Programmers  (SP) 

2.3.3  Testers  (ST) 


t 

e 


2.4  Contractual  Data 

These  data  values  are  organized  into  three  sets  as  described 
and  decomposed  below.  It  should  be  understood  that  while  each  data 
element  does  impact  the  development,  it  may  be  difficult  to 
objectively  quantify  its  effect.  A  default  value  of  "one"  would  be 
used  for  unknowns  (e.g.,  contractor  not  yet  selected).  Otherwise, 
subjective  or  consensus  values  can  be  initially  established  by  the 
users  based  on  the  guidance  provided. 


2.4.1  Contract  Factors  DIRECT 

a.  Contract  type  (CC.TYPE)  1 

(1)  CPFF  1 

(2)  Cost  Sharing  (indicate  formula)  _ 

(3)  Fixed  Price  1.10 

(4)  Contract  Extension  .95 

(5)  Other 


b.  Requirements  Definition  Quality  (CC.REQU) 
(estimate  impact  of  each) 

(1)  Completeness  (CC.COMPL) 

(2)  Clarity  (CC. CLEAR) 

(3)  Verifiability  (CC.VERIF) 

(4)  Quality  Assurance  (CC.QA) 


c.  Schedule  Urgency  (CC.SCHED) 


(1)  High  H 

(2)  Medium  M 

(3)  Low  L 

d.  Cost  Realism  (CC.COST) 

(1)  Sole  Source  Negotiation  1.10 

(2)  Normal  Competition  1.0 

(3)  Buy  In  1.10 

(4)  Other 


2.4.2  Buyer  (Procurement  Agency)  Factors  (CB) 


a.  Buyer  Membership  (CB.MEMBR) 

(1)  Single  Using  Agency 

(2)  Multiple  Users 

(3)  Multi-Service 

b.  Monitoring  Policy  (CB.MONTR) 

(1)  Arms  Length 

(2)  Work  Sharing 

(3)  Distance 

a)  Together  (on-site) 

b)  Frequent  Visit 

c)  Travel  Restraints 

c.  Personnel  Experience  (CB.EXPER) 

(TBD) 

d.  Flexibility 

(1)  Requirements  (CB.FLEXR) 

(2)  Quality  (CB.FLEXQ) 

2.4.3  Maker  (Contractor)  Factors 

a.  Management/Organization  (CM.MGMT) 

b.  Technical  Organization  (CM.TECHO) 

(1)  Chief  Programmer  Teams 

(2)  Design/ Programmer  Teams 

(3)  Design  Teams/Programmer  Teams 

(4)  Other 


c.  Developmental  Practices  (CM.PRACT) 

(1)  Design  Verification  (CM.VERIF) 

a)  Independent  Interface  Reviews  .94 

b)  Design/Program  Walkthrough  .90 

c)  Other 

(2)  House  Standard  Practices  (CM.STND) 

(Estimate  impact  of  each) 

a)  Completeness 

b)  Quality 

c)  Enforcement 

(3)  Design  Approach  (CM.APRCH) 


a)  Top  Down  .92 

b)  Doers  Choice  1.00 

c)  Other 

d.  Managerial/Systems  Experience  (CM.EXPRN)  (TBD) 

e.  Manning  Stability/Turnover  Rate  (CM.STBL)  (TBD) 

f.  Manning  Availability  Level  (CM. MANN) 

1)  High  H 

2)  Medium  M 

3 )  Low  L 


3.  Input  Parameter  Aggregation 

In  this  section,  the  data  obtained  per  para.  2  are  aggregated 
such  that  items  that  jointly  contribute  to  any  particular  Effort 
Level  determinant  (per  para.  4)  are  joined  together. 

In  the  notation  used  below,  the  underline  calls  attention  to 
aggregated  data  items  whose  constituants  are  defined  subsequently. 

3.1  Contractual  Data  Items 

3.1.1  Common  Factor  (CG)  Calculations 
CG  =  (CC) (CB) (CM) 
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3. 1.1.1  Contractual  Factor  (CC) 


CC  =  (CC.TYPE) (CC.COST) (CC.REQU) 

CC.REQU  =  (CC . COMPL) (CC .CLEAR) (CC . VERIF) (CC . QA) 

3. 1.1.2  Contracting  Agency  (Buyer)  Factor  (CB) 

CB  =  (CB .MEMBR) (CB .MONTR) (CB .EXPER) (CB.FLEXR) (CB .FLEXQ) 

3. 1.1. 3  Contractor  (Maker)  Factor  (CM) 

CM  =  (CM. MGMT) (CM . STBL) (CM.EXPRN) 

3.1.2  Contractor  Implementation  Organization  (CM.IMPL) 

CM.IMPL  =  (CM.PRACT) (CM.TECHO) 

CM . PRACT  =  (CM. VERIF) (CM.APRCK) (CM.STNDS) 

3.1.3  Project  Staffing  Level  (CG.STAF) 

This  relationship,  which  uses  input  items  CC.SCHED  and  CM. MANN 
is  described  in  para  6.2. 

3.2  Product  Definition  Data 

3.2.1  Component  Criticality  (PG.CRIT) 

This  component  sums  up  three  attributes  that  can  influence  the 
developmental  effort.  These  can  apply  at  the  CPC  or  CPCI  level. 

a.  Time  (PP.TIM)  and  Storage  (PP.STR)  Criticality. 

Each  of  these  factors  is  treated  as  an  exponential  variable 
that  is  dependent  on  the  estimated  ratio  between  what  is  needed 
versus  what  is  provided.  If  the  needed  is  less  than  one-half  that 
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provided,  the  factor  is  set  to  One;  i.e.,  is  not  critical.  If  it  is 
greater  than  one-half,  criticality  is  computed  as  follows: 

PP .TIM  =  e**Kt(TIM.RATI0-0.5),  with  Kt=2 

PP.STR  =  e**Ks (STR. RATI 0-0 . 5) ,  with  Ks=2 

b.  Calculation  of  Criticality 

PG.CRIT  =  (PP .TIME) (PP . STR) (PG .RELY) 

3.2.2  Special  Test  Requirements  (PT.SPECL) 

(Direct  Factors  apply  to  test  effort;  AFT  to  Test  Documentation 
Effort) 

PT.SPECL  =  (PT.FLT)(PT. SITE) (PT. LOAD) 

PT.SPECL. AFT  =  (PT.FLT . AFT) (PT. SITE . AFT) (PT. LOAD .AFT) 

3.2.3  Normalized  Size  Summaries 

Three  effective  sizes  of  the  program  (CPCI)  are  obtained,  one 
each  for  Design,  Programming  and  Test  activities.  They  are  obtained 
by  normalizing  the  actual  size  of  each  CPC  to  account  for  its  value 
of  newness,  complexity  and  criticality. 

a.  If  data  is  entered  on  a  CPC  basis  it  is  summed  as  follows: 

n 

PD. SIZE  =ST/PP.SIZE. IN)c*(PD.NEW)c*(PD.PLEX)c*(PG.CRIT)c 

C=1 

n 

PP . SIZE  =y^(PP-SIZE. IN)c*(PP.NEW)c*(PP.PLEX)c*(PG.CRIT)c 

C=1 

n 

PT. SIZE  =y^(PP.SIZE.IN)c*(PT.NEW)c*(PT.PLEX)c*(PG.CRIT)c 
c=l 
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b.  If  data  is  entered  on  a  CPCI  basis,  the  calculation  is  the 
same,  but  the  summation  is  not  applicable. 

c.  If  both  CPC  and  CPCI  data  is  entered,  method  a  above  is 
used,  but  with  equivalent  CPCI  data  being  substituted  for  any 
missing  CPC  level  data. 

3.2.4  Product  Requirments 

PD  =  (PD.SIZEHPG.SOFTW) 

PP  =  (PP.SIZE)(PG. SOFTW ) 

PT  =  (PT. SIZE) (PG. SOFTW) (PT.SPECL)(PTD. AFT) 

3.2.5  Test  Documentation  Requirements  (PTD) 

Two  products  are  computed  for  the  three  contributers ;  one  for 
the  "direct  effects"  the  other  for  "after  effects."  The  latter  is 
applied  against  the  test  effort  calculations: 

(PTD)  =  (PTD.APRVL) (PTD. DTAIL) (PTD. PERM). 

(PTD. AFT)  =  (PTD. APRVL. AFT) (PTD. DTAIL. AFT)(PTD. PERM. AFT). 

3.3  Methods  Data 

3.3.1  Design  Method  (MD) 

a.  Direct  Effect  Factor 

MD  =  (MD.REPR) (CM. IMPL) 

b.  After  Effects  Factor 
MD. AFT  =  (MD.REPR. AFT) 

3.3.2  Programming  Method  (MP) 
a.  Direct  Effect  Factor 

MP  =  (MP.METH) (MD.AFT) (CM. IMPL) ■ 

MP.METH  =  (MP . FCLTY) (MP . LINGO) (MP ■ ACCES ) 

MP.FCLTY  =  (MP . CAP) (MP .CNFIG) (Mn . DBUG) (MP . LIBR) (MP . EXRSZ) 
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b.  After  Effect  Factor 

MP.AFT  =  CMP . FCLTY  AFT')  (MP ■  LINGO ■  AFT)  CMP ■  ACCES . AFT) (MD ■  AFT) 
MP.FCLTY.AFT  = 

CMP . CAP . AFT) CMP . CNFIG . AFT) CMP . DBUG . AFT) CMP . LIBR . AFT) CMP . EXRSZ . AFT) . 

3.3.3  Test  Method  CMT) 

MT  =  C MT. AVAIL) CMT .UTIL) CMP. AFT) CCM.IMPL) 

MT. AVAIL  =  CMT. ACCES) (MT.CAP)CMT. RELY) 

MT.UTIL  =  (MT. INPUT) CMT. OUTPT) (MT. OPER) 

3.4  Staff  Experience  Factors 

(TBD) 

4.  Effort  Level  Computation 

Effort  level  values  are  indictors  of  the  amount  of  effort  to  be 
expended  in  the  conduct  of  each  of  the  seven  major  activities  into 
which  the  total  effort  is  divided,  as  follows: 

a.  Design  (ED) 

b.  Programming  (EP) 

c.  Test  (ET) 

d.  General  (a  composite  of  the  above  activities)  (EG) 

e.  Program/Design  Documentation  (e.g.,  the  product  specification) 
(EDD) 

f.  Test  Documentation  (Plans,  Procedures,  Reports)  (ETD) 

g.  User  (and  other)  Documentation  (EGD) 

The  unit  of  each  of  these  efforts  is  program  size  (i.e. ,  the 
equivalent  total  number  of  executable  machine  instructions)  that  has 
been  adjusted  to  account  for  all  project  parameters  treated  in 
paragraph  3,  including  those  that  affect  productivity. 

4.1  Main  Activity  Effort  Level 


a. 

Design 

ED 

=  (PD)(MD)(SD)(CG). 

b. 

Programming 

EP  =  (PP) (MP) (SP) (CG) 

c . 

Test : 

ET  = 

(PT) (MT) (ST) (CG) . 
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4.2  Composite  (General)  Activity  Effort  Level  (EG) 

This  general  level  is  used  to  account  for  all  activities  that 
do  not  fall  within  the  six  explicit  activities  identified  in 
paragraph  4.  It  consists  of  a  weighted  average  of  the  three  main 
activities,  as  follows: 

EG  =  [Kd(ED)+Kp(EP)+Kt (ET) ] / (Kd+Kp+Kt ) . 

The  initial  weights  are:  kd  =  15,  kp  =  10,  and  kt  =  12 

Note,  that  the  Programming  Weight  Factor  (Kp)  is  larger  than  is 
generally  attributed  to  this  activity  because  in  this  analysis,  it 
includes  all  program  debug,  integration  and  checkout  work. 

4.3  Documentation  Activity  Effort  Levels. 

a.  Program/Design:  EDD  =  (PDD) (PD) (MD.AFT) (SD) (CG) 

b.  Test:  ETD  =-  (PTD) (PT . SIZE) (PG . SOFTW) (PT. SPECL. AFT) (CG) 

PTD  =  (PTD.APRVL) (PTD. DTAIL) (PTD. PERM) 

c.  User:  EGD  *  (PGD) (EG) 

5.  Generic  Conversion  Factor  Computation 

The  Generic  Conversion  Factors  are  ratios  between  two  sets  of 
Effort  Factors.  The  denominators  are  obtained  by  the  application  of 
the  effort  level  calculations  to  the  Base  Project;  i.e.,  the  project 
that  provided  the  quantitative  basis  for  the  SWAP  model.  The 
numerators  are  the  same  factors,  but  applied  to  any  (Target) 
project . 

5.1  Generic  Factor  Calculations 

GD  =  (ED.TRGT)/(ED. BASE)  GDD  =  (EDD. TRGT)/ (EDD. BASE) 

GP  =  ( EP. TRGT) / (EP. BASE)  GTD  =  (ETD. TRGT) /(ETD. BASE) 

GT  =  (ET. TRGT) / (ET. BASE)  GGD  =  (EGD. TRGT) /(EGD. BASE) 

GG  =  (EG .TRGT)/ (EG. BASE) 

5.2  Base  Project  Calculations 

The  input  parameter  selections  and  values  for  the  Base  Project 
are  presented  in  four  Tables  of  Attachment  K-A  as  follows: 

Table  K-A.l  Base  Project  Product  Input  Factors  -  CPCI  Level 
Table  K-A. 2  Base  Project  Product  Input  Factors  -  CPC  Level 
Table  K-A. 3  Base  Project  Methods  Input  Factors 
Table  K-A. 4  Base  Project  Common  Input  Factors 
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Based  on  these  inputs,  the  resulting  Effort  Level  values  are 
computed  in  Attachment  K-A.  These  same  Effort  Values  are  also  shown 
in  an  abbreviated  form  in  Attachment  K-B,  for  ease  of  comparison 
with  Target  project  values. 

5.3  Target  Project  Calculations 

A  set  of  user  input  data  reflective  of  two  sample  target 
projects  are  provided  in  Attachment  K-B.  The  seven  effort  factors 
are  calculated  for  each  using  the  same  relationships  shown  in  Para. 
5.2.  The  Generic  Factor  ratios  shown  in  Para.  5.1  are  then  formed, 
as  shown  below: 


Generic  Factor 

Project  X2 

Project/2 

GD 

Design  Factor 

1.53 

0.32 

GP 

Programming  Factor 

1.15 

0.38 

GT 

Test  Factor 

0.87 

0.24 

GG 

General  Composite  Factor 

1.18 

0.31 

GDD 

Design/Program  Documentation 

1.61 

0.27 

GTD 

Test  Documentation 

1.27 

0.27 

GGD 

General/User  Documentation 

1.18 

0.22 

6.  Box  Conversion  Factors 


Three  kinds  of  data  transformers  are  needed  for  application  to 
specific  boxes.  One  transforms  manning  levels,  another  activity 
durations,  and  the  last  applies  to  Decision  Probabilities.  The 
specific  transformations  factors  are  derived  from  three  contributing 
considerations . 

a.  Activity  Type:  The  Generic  Conversion  Factors  derived 
in  Par.  5  account  for  the  principal  type  of  activity 
represented  by  the  box. 

b.  Growth  Type:  Certain  (highly  fragmented)  activities 
can  grow  just  by  increased  manning;  the  other  (more 
integrated)  activities  also  need  more  time. 

c.  Manning  Level:  Personnel  Availability  and  Contractual 
Schedule  Urgency  influence  the  totality  of  available 
personnel  that  are  assigned  to  the  project. 

On  later  versions  of  the  Model,  another  set  of  factors  will  be 
developed  to  account  for  user  uncertainties  about  the  project.  These 
levels  will  depend  initially  on  the  kinds  of  input  data  that  is  selected 
via  default.  Later  versions  will  permit  the  user  to  express  his 
confidence  level  with  each  item  of  input. 
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6.1  Transformation  Class  (BG. CLASS)  Assignments 


A  set  of  15  transformation  classes  (BG. CLASS)  have  been  established 
to  provide  for  combinations  involving:  Activity  Type,  Documentation,  and 
Growth  Type. 

The  classes  are  identified  by  three  letters  "AGD"  as  follows: 

A  =  Basic  Activity:  D  =  Design;  P  *  Programming;  T  =  Test;  G  =  General. 

G  =  Growth  Pattern:  F  =  Fragmented;  I  =  Integrated;  K  =  Constant. 

D  =  Documentation  Task,  if  present;  otherwise,  it  is  omitted. 

For  example,  "TFD"  indicates  a  Test  Activity,  with  Fragmented  Growth, 
involving  Documentation. 

Fourteen  of  these  classes  are  derived  from  the  seven 
Activity/Documentation  Activities  and  two  of  the  Growth  Types  (i.e., 

F&I).  The  fifteenth  class  includes  all  boxes  that  have  type  K  (constant) 
growth.  This  latter  class  is  provided  to  allow  any  project  unique  boxes 
to  retain  their  assigned  data. 

The  assignment  of  all  system  boxes  among  of  the  15  classes  is  given 
in  Table  K-l. 

6.2  Staff  Availability  Factor  (CG.STAF) 

Staff  Availability  is  derived  from  two  inputs: 

Schedule  Urgency  (CC.SCHED)  may  be  high,  medium,  or  low 
Manning  Availability  (CM. MANN)  may  be  high,  medium,  or  low 

CG.STAF  is  derived  per  the  following  matrix: 

Staff  Availability 


H  M  L 


Schedule 

H 

1.3 

1.2 

1.0 

Urgency 

M 

1.1 

1.0 

0.9 

L 

1.0 

0.8 

0.7 

e.g.,  If  Availability  is  "M"  and  Urgency  is  "H",  then  CG.STAF  =  1.2. 


On  later  SWAP  Models,  the  staff  availability  derived  above  can 
be  "shaded"  to  compensate  for  the  coarseness  of  the  matrix. 
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Table  K-l .  Box  Activity  Group  (BG. GROUP)  Assignments 


Box  ID 

BG. GROUP 

Box  ID 

BG. GROUP 

1Y,  2A, 

GI 

48 A,  Y 

TID 

ALL  4 

GID 

48B 

TFD 

ALL  6,  All  8 

DI 

50  All 

TID 

10A,C,E,L,N,Y 

DF 

52  All 

TID 

10H,  J 

DI 

12A, C.G 

DI 

53  All 

GK 

12J 

DF 

54A,D,E,H,K,L,M 

TI 

Q.s.w.y 

54P,T,V 

TID 

14A 

PI 

60  All 

GK 

14C 

PF 

62  All 

GK 

16A,C,Y 

PF 

66  All 

(X 

18C,D 

PF 

70A,B,C,E 

GID 

18E,F,G,I,J,K,L 

PI 

72A,C 

GID 

74A,B,C 

GID 

8CA,J,L,N,P 

DFD 

80E 

GID 

M,N,0,P,Q,Y,X 

20A,C,E 

DI 

82A,E,G, J,P,Q,S,T 

DID 

V,W,X,Y 

22A.Y.23A 

PI 

84Y 

GID 

24A,C,E 

DFD 

25C 

PI 

26A.28A 

DID 

All  40 

TID 

42M,N,G,H 

TID 

42A,C,E,J,K,Y 

TFD 

All  44 

TF 

46A,C,L,P,Y 

TF 

46R,S,T 

TI 

47Y 

TFD 
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6.3  Box  Transformation  Factors  Computation 

6.3.1  Manning  Levels  Factor  (BG.MANN) 

a.  For  all  boxes  designated  as  fragmented  the  Manning 
Level  Factor  shall  be  the  product  of  the  Staff 
Availability  and  the  Generic  Conversion  Factor 
assigned  to  the  box.  For  example,  if  a  box  is  in 
group  TFD: 

BG.MANN  =  (GTD)(CG.STAF) 

b.  For  all  boxes  designated  as  Integrated,  BG.MANN  shall 
be  the  square  root  of  the  above  product.  For  example, 
on  boxes  within  Class  DI: 

BG.MANN  =  SQ.RT  [ (GD) (CG. STAF) ] 

6.3.2  Activity  Duration  Factor  (BG.DUR) 

a.  The  following  table  shows  the  dependency  of  duration 
(BG.DURA)  on  Staff  Availability.  It  reflects  changes 
in  the  relative  developmental  productivity  induced  by 
manning  level,  per  the  following  equation: 

(CG. STAF) (BG.DURA) (PRODUCTIVITY)  =  1 


CG . STAF  .6  .7  .8 

.9 

1 

1.1 

1.2 

1.3 

1.4 

BG.DURA  1.51  1.31  1.17 

1.07 

1 

.96 

.93 

.90 

.89 

Productivity  1101  1091  107% 

1041 

1001 

951 

901 

851 

801 

b.  The  relative  productivity  of  the  developmental  process 
is  also  affected  by  the  magnitude  of  the  project  as 
reflected  in  each  Generic  Factor.  This  impacts  the 
duration  by  the  Factor  BG.DURM  which  increases  (from 
Base  value  of  1)  by  Ml  for  each  doubling  of  the 
"Generic  Conversion  Factor"  and  decreases  by  Ml  for 
each  halving.  This  relationship  (for  M*5l)  is  shown 
in  the  following  table: 

Generic  Factor  .25  .5  1  2  4  8 

Productivity  1101  1051  1001  951  901  85% 

BG.DURM  .91  95  1.00  1.05  1.11  1.18 

c.  For  all  boxes  designated  as  fragmented; 

BG.DUR  *  (BG.DURA) (BG.DURM) 
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d.  For  all  boxes  designated  as  Integrated 

BG.DUR  =  (BG.DURA) (BG.DURM)  SQ.RT  (Generic  Conversion 

Factor) 

6.3.3  Probability  Transformation 

In  general  the  probability  of  initial  success  diminishes  as  the 
relative  magnitude  of  an  activity  increases  and  also  as  the  level  of 
manpower  increases.  For  this  reason,  the  product  of  the  Generic 
Conversion  Factor  (e.g.,  GD)  and  the  Staff  Availability  (BG.STAF) 
shall  be  used  as  the  Decision  Affecting  Parameter  BG.DCIDE;  i.e.: 

BG.DCIDE  =  (CG. STAF) (Generic  Conversion  Factor) 

For  each  doubling  of  "BG.DCIDE1'  the  yes  probability  (pYES) 
shall  decrease  to  D%  of  its  prior  value.  For  each  halving  of 
"BG.DCIDE";  the  pNO  (=  1  -  pYES)  shall  decrease  to  D%  of  its  prior 
value.  This  relationship  (for  D®94%)  is  expressed  in  the  following 
table  that  shows  how  pYES  varies  with  "BG.DCIDE"  values. 


BG.DCIDE  = 

1/8 

1/4 

1/2 

1 

2 

4 

8 

pYES  * 

34 

30 

25 

20 

19 

18 

16 

51 

47 

44 

40 

38 

35 

33 

67 

65 

62 

60 

56 

53 

49 

84 

82 

81 

80 

75 

70 

66 

Any  base  probability  values  of  00  or  100  shall  remain  unchanged. 

6.4  Uncertainty  Computation 
(TBD) 

7.  Box  Value  Transformations 

7.1  Activity  Group  Assignments 

Each  box  that  is  an  Activity,  Decision,  or  Personnel  type  is 
assigned  to  an  activity  group  as  shown  in  Table  K-l.  The  duration, 
manning,  and  decisional  values  (as  applicable)  for  each  of  these 
boxes  shall  be  transformed  from  their  base  values  using  the  factors 
presented  in  Section  6. 

7.2  Uncertainty  Assignments 

(To  be  provided  on  later  models) 
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PG.CRIT  -  < PP.TIM) (PP.STR)(RELR)  -  ( 1 . 5)( 1 .2)( 1 )  -  1.8 
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K-B  ATTACHMENT 
TO  APPENDIX  K 


Sample  SWAP  Target  Projects  Parameters  vs.  Base 


CPCI  ID 

PRODUCT  (All  at  CPCI  level") 

X2 

11 

BASE 

SIZE  (X100) 

1600 

400 

800 

NEW-D 

.90 

.80 

.83 

NEW-P 

1.00 

.90 

.91 

NEW-T 

.90 

.80 

.99 

PLEX-D 

1.2 

1.0 

1.11 

PLEX-P 

1.0 

1.2 

1.10 

PLEX-T 

1.1 

0.9 

0.90 

CRIT 

1.2 

1.1 

1.4 

PG . SOFTW 

1 

1 

1 

PT.SPECL 

1.30(1. 

15)  1.10(1.05) 

1.15(1.30) 

DOCUMENTATION 

PDD 

1.0 

.85 

1.0 

PTD.APRVL 

.85(1.0) 

1. 0(1.0) 

1. 0(1.0) 

.DTAIL 

.75(1.2) 

1. 0(1.0) 

1. 0(1.0) 

.PERM 

1.K.95) 

1. 0(1.0) 

1. 0(1.0) 

PGD 

1.0 

.70 

1.0 

METHOD 

X2 

X/2 

BASE 

MD.REPR 

0.90(0.85) 

1.05(0.95) 

1.00(1.00) 

MP. LINGO 

1 . 2 ( . 85 ) 

1.3(1.25) 

1. 0(1.0) 

MP.FCLTY 

. 95 ( . 95) 

0.9( .95) 

1.02(1.02) 

MP.ACCES 

0.95(0.92) 

1. 0(1.0) 

1.07(1.15) 

MT.ACCES 

1.04 

1.00 

1.04 

MT.CAP 

1.0 

.95 

1.00 

MT.RELY 

1.0 

1.05 

1.00 

MT. INPUT 

0.95 

0.95 

1.00 

MT.OUTPT 

0.97 

1.00 

.95 

MT.OPER 

1.00 

1.00 

1.00 
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PREVIOUS  PACE 


STAGING  -  Default 


♦Parentheses  indicate  "AFT"  factor  values 


COMMON  FACTORS 

X2 

11 

BASE 

CC . TYPE 

1.05 

1.10 

1.00 

CC . REQU 

1.10 

.95 

1.15 

CC . SCHED 

M 

L 

M 

CC . COST 

1.0 

1.05 

1.00 

CB . EXPER 

1 

1 

0.95 

CB . MEMBR 

1.04 

1.0 

1 

CB.MONTR 

0.92 

1.0 

1.0 

CB . FLEXR 

0.85 

1.0 

l.C 

CB . FLEXQ 

1.0 

0.90 

0.95 

CM . MGMT 

1.0 

0.95 

0.95 

CM.TECHO 

0.95 

0.85 

0.95 

CM.VERIF 

0.85 

0.90 

0.85 

CM.STND 

0.93 

0.95 

0.95 

CM.APRCH 

0.92 

0.95 

1. 

CM.EXPRN 

0.98 

1.0 

0.92 

CM.STBL 

0.92 

0.95 

0.90 

CM. MANN 

L 

H 

M 

168 


GLOSSARY 


AFLC 

AFSC 

ATM 

Box.Proc 

CCI&C 

CDR 

Cl 

CPCI 

CPDP 

CPC 

CPT&E 

CRISP 

CSDCA 

DELIV 

DEV 

DID 

DIG 

DOC 

DSGN 

ECP 

ESD 

FACIL 


Air  Force  Logistics  Command 
Air  Force  Systems  Command 
Activity  Timing  and  Manpower  Data 

The  label  assigned  to  the  Simulator  Event  Notice  type 
which  proceses  each  Model  function  box 

Code,  Compile,  Integrate  and  Checkout 

Critical  Design  Review 

Configuration  Item 

Computer  Program  Configuration  Item 

Computer  Program  Development  Plan 

Computer  Program  Component 

Computer  Program  Test  &  Evaluation 

Computer  Resources  Integrated  Support  Plan 

Center  for  Software  Data  Collection  and  Analysis 

Deliver 

Develop 

Data  Item  Description 
Developmental  Integration  Group 
Document 
Designer 

Engineering  Change  Proposal 
Electronic  Systems  Division 
Facility 
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GLOSSARY  (Continued) 


FCA 

Functional  Configuration  Audit 

Flow 

The  label  assigned  to  the  Simulator  Event 
which  controls  box-to-box  transition 

Notice  type 

FQT 

Formal  Qualification  Testing 

FSD 

Full-Scale  Development 

HiSim 

High  Simulation  Level 

I&C 

Integration  and  Checkout 

LoSim 

Low  Simulation  Level 

MGMT 

Management 

No. Succ 

Decision  Box  Successor  List  (if  "No"  Exit 

is  Taken) 

ORG 

Organize 

OTD 

Occurrence  and  Timing  Data 

PCA 

Physical  Configuration  Audit 

PDR 

Preliminary  Design  Review 

PERT 

Program  Evaluation  and  Review  Technique 

PM 

Program  Manager 

PMR 

Program  Management  Review 

PO 

Program  Office 

PQT 

Preliminary  Qualification  Testing 

Pred 

Function  Box  Predecessor  List 

PROC 

Procedure 

PRGM 

Program 

PRGMRS 

Programmers 

GLOSSARY  (Concluded) 


PROD 

PROJ 

QUAL 

RFP 

SARE 

SCEWG 

SEMP 

SPEC 

SPRT 

SYS 

TAC 

TEMP 

TIG 

TO  I 

Yes . Jucc 


Produce 
Project 
Qualification 
Request  for  Proposal 

Software  Acquisition  Resource  Expenditure 

Software  Cost  Estimation  Working  Group 

System  Engineering  Management  Plan 

Specification 

Support 

System 

Tactical  Air  Command 

Test  and  Evaluation  Master  Plan 

Test  Integration  Group 

Computer  Systems  Engineering  Directorate 

Function  Box  Successor  List  (if  "Yes"  or  Only  Exit  it 
Taken) 
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